[sakai2-tcc] Proposal: eliminate all indies, re-version trunk to CLE 4.0

Mark J. Norton markjnorton at earthlink.net
Tue Jun 18 06:00:19 PDT 2013 

 >  I guess we are no longer fans of the Java way of versioning

Personally, I thought the Java versioning of 1.5 = 5.0 was one of the 
stupidest things I'd ever seen.  EVERYBODY calls it Java5, yet 
technically it is Java version 1.5.  Consider the amount of language 
improvements made over 1.4, it was clearly a generational advance - but 
just a dot release.  Oracle seems quite content to continue in that 
tradition as well.

I'd like to think that the Sakai community was better than that. I also 
favor incrementing Sakai to 4.0.

- Mark

On 6/18/2013 8:53 AM, Aaron Zeckoski wrote:
> I like that idea as well.
> 4.0, 4.1, 4.2, 4.3 and the next major release is 5.0
>
> I guess we are no longer fans of the Java way of versioning (1.0...
> 1.4, 1.5=5.0, 1.6=6.0, 1.7=7, etc...)? We seem to be a lot closer to
> that mechanism currently.
>
> -AZ
>
>
> On Tue, Jun 18, 2013 at 8:49 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> I would definitely support this. And in terms of release process there is no
>> difference in going from version 4.0.1 to 4.1 instead.
>>
>>
>> On Tue, Jun 18, 2013 at 10:41 PM, Bryan Holladay <holladay at longsight.com>
>> wrote:
>>> I'd like to see this go one step further and speed up our major version
>>> increments.  Sakai has been on version 2 since I started working on it
>>> (almost 7 years ago).  This makes is look like the product is just treading
>>> water.  The new approach to versioning seems to be fast increments (just
>>> look at your browser versions, Sakai is older than Chrome and Chrome is on
>>> version 27).  I'm not suggesting we move that fast, but just faster than we
>>> have in the past.  Possibly even getting rid of the 3rd version digit and
>>> just do 2: e.g. 4.1, 4.2, 4.3, 5.0, 5.1 ...   Putting on my SCA hat, it's a
>>> lot easier to "sell" Sakai when the major version changes more than once
>>> every 10 years.
>>>
>>> -Bryan
>>>
>>>
>>> On Tue, Jun 18, 2013 at 8:25 AM, Steve Swinsburg
>>> <steve.swinsburg at gmail.com> wrote:
>>>> If I was there I would have definitely brought it up, so just assume it
>>>> was discussed also ;)
>>>>
>>>> cheers,
>>>> Steve
>>>>
>>>>
>>>> On Tue, Jun 18, 2013 at 10:23 PM, Aaron Zeckoski <azeckoski at unicon.net>
>>>> wrote:
>>>>> I want to echo pretty much all of these (and in a sign that these are
>>>>> good points, they all came up at the conference meeting... except the
>>>>> odd numbers one.... but close enough).
>>>>> :-)
>>>>> -AZ
>>>>>
>>>>>
>>>>> On Tue, Jun 18, 2013 at 8:01 AM, Steve Swinsburg
>>>>> <steve.swinsburg at gmail.com> wrote:
>>>>>> A few late night thoughts on the 4.0 jump.
>>>>>>
>>>>>> 1. I've never liked 2.10 as a version, once you get into double digits
>>>>>> it
>>>>>> looks weird and is almost like 2.1.
>>>>>> 2. We could go to 3 but there is too much confusion with Sakai3/3akai.
>>>>>> Also
>>>>>> 3akai is still being used as the OAE fronted name.
>>>>>> 3. Re-versioning all projects means that in order to avoid conflicts
>>>>>> with
>>>>>> existing versions and to not go backwards, we need to go forwards, and
>>>>>> the
>>>>>> next version is 4.0. We already have a 3.0 for msgcntr so we can't go
>>>>>> back
>>>>>> to 2.10 for that without it being super confusing.
>>>>>> 4. CLE 4 has a cool ring to it.
>>>>>> 5. No one likes odd numbers?
>>>>>>
>>>>>> cheers,
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 18, 2013 at 9:53 PM, May, Megan Marie <mmmay at indiana.edu>
>>>>>> wrote:
>>>>>>> Is 4.0 supposed to follow 2.9.3?    I’d like to see some
>>>>>>> justification for
>>>>>>> jumping to this version.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: sakai2-tcc-bounces at collab.sakaiproject.org
>>>>>>> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of
>>>>>>> Steve
>>>>>>> Swinsburg
>>>>>>> Sent: Tuesday, June 18, 2013 12:58 AM
>>>>>>> To: Anthony Whyte
>>>>>>> Cc: sakai2-tcc Committee
>>>>>>> Subject: Re: [sakai2-tcc] Proposal: eliminate all indies, re-version
>>>>>>> trunk
>>>>>>> to CLE 4.0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Wow 4.0, interesting. I can see the CLE4 logo already! Yes I would
>>>>>>> like to
>>>>>>> help. We have the sakaiproject org in github, Noah could possibly
>>>>>>> move the
>>>>>>> repo there before we begin? It's almost like how nakamura was always
>>>>>>> a fork
>>>>>>> of ieb. But it's transient so it doesn't matter I guess.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Let's flesh out what tasks need to be done so we can take parts and
>>>>>>> get it
>>>>>>> done.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>
>>>>>>> On 18/06/2013, at 7:04, Anthony Whyte <arwhyte at umich.edu> wrote:
>>>>>>>
>>>>>>> The proposal below plays off our discussions in San Diego relative to
>>>>>>> working towards a simplified build/deploy process.  It represents an
>>>>>>> incremental step but I think warranted given the failure of the indie
>>>>>>> approach to capture the imagination of the Sakai Community and the
>>>>>>> attendant
>>>>>>> "version" confusion often encountered by local deployers attempting
>>>>>>> to track
>>>>>>> and manage CLE release changes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The proposal represents a first step in the
>>>>>>> simplification/rationalization
>>>>>>> process.  I can make time to do the work starting this week, if it
>>>>>>> meets
>>>>>>> with your approval.  If Steve and Matt have any time to help all the
>>>>>>> better.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> PROPOSED CHANGES (limited to trunk)
>>>>>>>
>>>>>>> a. All CLE modules will be versioned 4.0-SNAPSHOT (no exceptions)
>>>>>>> b. All CLE module base poms will inherit from the master pom as their
>>>>>>> <parent>.   The Kernel and CLE master pom will retain their
>>>>>>> oss-parent
>>>>>>> <parent>.  The CLE base pom will continue to inherit from the master
>>>>>>> pom.
>>>>>>> c. All CLE module assembly code will be deleted and references to
>>>>>>> assembly
>>>>>>> <module> will also be removed from module poms (e.g.,
>>>>>>> <module>basiclti-assembly</module> will be deleted).
>>>>>>> d. All CLE module poms that include explicit version references to
>>>>>>> Sakai
>>>>>>> dependencies will be updated.  When appropriate I'll swap in Maven
>>>>>>> property
>>>>>>> variables.
>>>>>>>
>>>>>>> e. Eliminate 34 CLE module version <properties> from the master pom
>>>>>>> rendered redundant by the switch to a single version for all CLE core
>>>>>>> modules.
>>>>>>>
>>>>>>> f.
>>>>>>> https://source.sakaiproject.org/svn/sakai/trunk/jstl-shared-deploy/
>>>>>>> will be deleted (rendered redundant by deploy/ poms)
>>>>>>>
>>>>>>> g. freebie: hybrid module will be eliminated from .externals and base
>>>>>>> pom
>>>>>>> build profiles.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> WORK WILL BE DONE IN GITHUB
>>>>>>>
>>>>>>> I will do my work in a local branch off my local fork of
>>>>>>> botimer/sakai-cle
>>>>>>> [1].   I'll create a branch called "no_indie" and make my changes
>>>>>>> there in a
>>>>>>> manner similar to the way Noah handled his spring work.  Noah keeps
>>>>>>> his repo
>>>>>>> sync'd with sakai-trunk changes and I will do the same with my local
>>>>>>> branch.
>>>>>>> I prefer to make all changes at once, test, and then provide a single
>>>>>>> patch
>>>>>>> that can be committed to SVN trunk.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OUT OF SCOPE FOR THIS PROPOSAL (but still on the table for CLE 4.0)
>>>>>>>
>>>>>>> Base/Master pom rationalization.  I recommend that we consider
>>>>>>> revising
>>>>>>> the base pom in a way that we end up with a pom not unlike the
>>>>>>> org.apache.apache pom,[2]  Everything else we move to the master pom,
>>>>>>> which
>>>>>>> would inherit from the base pom, which would inherent from the
>>>>>>> oss-parent.
>>>>>>>
>>>>>>>              oss-parent
>>>>>>>
>>>>>>>                          Sakai base pom
>>>>>>>
>>>>>>>                              project info, repos, distribution
>>>>>>> management,
>>>>>>> plugin management, plugins
>>>>>>>
>>>>>>>                                      Sakai master pom
>>>>>>>
>>>>>>>                                  build profiles (from base pom),
>>>>>>> properties, dependencies, build, reporting
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note: changing the order of inheritance as suggested about would
>>>>>>> impact
>>>>>>> some contrib projects negatively.  We would need to either be
>>>>>>> prepared to
>>>>>>> help patch such projects or sufficient warning and simple steps on
>>>>>>> how to
>>>>>>> fix the <parent> element of contrib project's base pom.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> IMPLICATIONS
>>>>>>>
>>>>>>> 1.  We return to a monolithic release process, circa Sakai 2.5.
>>>>>>> Leaving
>>>>>>> aside Ian's reasons for creating kernel as the first indie, a
>>>>>>> commitment to
>>>>>>> shorter release cycles should provide a counterweight to the original
>>>>>>> rationale for creating tool indies, i.e., the need for off-cycle
>>>>>>> releases of
>>>>>>> important bug fixes or new functionality in order to compensate for
>>>>>>> overlong
>>>>>>> CLE release cycles.  However, without a commitment to shorter release
>>>>>>> cycles, eliminating indies could prove counterproductive.
>>>>>>>
>>>>>>> 2.  Faster downloads (no assemblies); consistent build/deploy
>>>>>>> behaviors
>>>>>>> for all modules (I should note that this has been addressed in trunk
>>>>>>> by
>>>>>>> importing the sakai-trunk-all approach).
>>>>>>>
>>>>>>> 3.  Elimination of version confusion.  All modules, all one version.
>>>>>>> Simple.
>>>>>>>
>>>>>>> 4.  A lag in the elimination of Jira confusion.  The SAK project can
>>>>>>> be
>>>>>>> bulked up with additional components, which if you are working on the
>>>>>>> latest
>>>>>>> stuff represents a gain; however, as Matt notes below, the Indie Jira
>>>>>>> projects will have to be retained for tracking earlier versions.  So
>>>>>>> no
>>>>>>> victory can be claimed here.
>>>>>>>
>>>>>>> 5.  Local build script changes.  I imagine some schools have crafted
>>>>>>> build
>>>>>>> scripts that accommodate the indies.  These scripts will need to be
>>>>>>> changed
>>>>>>> (simplified).  So a local impact cannot be discounted.
>>>>>>>
>>>>>>> 6. trunk devs will need to need to a fresh check out and clean
>>>>>>> install
>>>>>>> when the poms are updated.  No biggie but it should be mentioned.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Feel free to add other implications or raise a material objection.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://github.com/botimer/sakai-cle
>>>>>>> [2]
>>>>>>>
>>>>>>> http://search.maven.org/remotecontent?filepath=org/apache/apache/13/apache-13.pom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Matthew Jones <matthew at longsight.com>
>>>>>>>
>>>>>>> Date: June 17, 2013 1:54:51 PM EDT
>>>>>>>
>>>>>>> To: Beth Kirschner <bkirschn at umich.edu>
>>>>>>>
>>>>>>> Cc: "sakai2-tcc at collab.sakaiproject.org Committee"
>>>>>>> <sakai2-tcc at collab.sakaiproject.org>
>>>>>>>
>>>>>>> Subject: Re: [sakai2-tcc] Is there any reason I should not change the
>>>>>>> LTI
>>>>>>> version in trunk to 2.10-SNAPSHOT ??
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sending email on a weekend usually means it will get missed (or at
>>>>>>> least a
>>>>>>> delayed response). I'll usually draft my weekend emails and send on
>>>>>>> Monday.
>>>>>>> ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> And yea, it was discussed at the conference and there was some notes
>>>>>>> here.
>>>>>>> (Project organization and release process simplification)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I read your email, Steve but haven't had time to respond to
>>>>>>> individual
>>>>>>> points. I believe I agreed 100% on the outline of the current
>>>>>>> problem/situation but wasn't sure about the solution. Really though
>>>>>>> any
>>>>>>> solution is okay with me and I agree the current process isn't
>>>>>>> feasible for
>>>>>>> the future. It's move of a question is who's going to put in the
>>>>>>> (supposedly
>>>>>>> volunteer) time to do it? Anthony said he'd look at it and I'd help
>>>>>>> him, but
>>>>>>> I'm pretty much booked with local work through the summer, so likely
>>>>>>> wouldn't be doing anything extensive until late September/October. I
>>>>>>> think
>>>>>>> this would be too disruptive for 2.9 but the proof of concept could
>>>>>>> be done
>>>>>>> in trunk.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As far as the 2.10 LTI question, you're free to set whatever version
>>>>>>> you
>>>>>>> want, but I think it would go to Steve's point and that doing this
>>>>>>> would
>>>>>>> mean that you wouldn't have LTI released tied to the releases of 2.10
>>>>>>> (when
>>>>>>> that starts getting released) so possibly a slower process than
>>>>>>> currently.
>>>>>>> And LTI has a separate project in JIRA which would need to be dealt
>>>>>>> with
>>>>>>> separately.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There are really 2 types of indies. Indies that *are* indies because
>>>>>>> they
>>>>>>> some other indie needed the api's (or some other dependency) from it
>>>>>>> in
>>>>>>> order to build. You can't release the indie without having released
>>>>>>> it's
>>>>>>> dependencies. Most of the indies are this type and these *could* be
>>>>>>> collapsed easier because the version matches up better and they're
>>>>>>> still in
>>>>>>> SAK. However this would require everything including any former
>>>>>>> indies that
>>>>>>> had dependencies on these to be monolithic UNLESS the dependencies
>>>>>>> we're
>>>>>>> independently released (can't be done easily with maven any way I
>>>>>>> know of)
>>>>>>> or move them all to a separate project like edu-services is,
>>>>>>> something like
>>>>>>> sakai-apis.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The indies that changed their version and have their separate JIRA
>>>>>>> project
>>>>>>> are harder, because if they're merged back into CLE, it will make it
>>>>>>> harder
>>>>>>> to track and report bugs against the old versions. If they remain
>>>>>>> outside of
>>>>>>> the CLE it will still make it hard to know that these exist as
>>>>>>> separate
>>>>>>> projects.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Then we have the problem of msgcntr which is version 3.x already. To
>>>>>>> get
>>>>>>> around that, we either have to change the maven artifactId or groupId
>>>>>>> for
>>>>>>> msgcntr or we'd have to go with all of Sakai beyond 3.x (this was
>>>>>>> part of
>>>>>>> the 4.x proposal). So it might have to be 4.0 instead of 2.10 just
>>>>>>> because
>>>>>>> of msgcntr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Unless you were really looking for something to do, I don't think I'd
>>>>>>> jump
>>>>>>> it with LTI yet. I'm hoping those interested will have a chance to
>>>>>>> talk
>>>>>>> about this more in the near future, ideally finding a time with Steve
>>>>>>> if he
>>>>>>> is going to be doing some of that work. I agree with the goal, I just
>>>>>>> need a
>>>>>>> better roadmap for getting there.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 17, 2013 at 1:05 PM, Beth Kirschner <bkirschn at umich.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Steve -- at the conference we had discussed abandoning the indie
>>>>>>> approach
>>>>>>> to most, if not all tools, in the next major release -- currently to
>>>>>>> be
>>>>>>> called 2.10 (or 4.0?).
>>>>>>>
>>>>>>> Chuck -- I like the idea of changing the next version of LTI to 2.10.
>>>>>>> +1
>>>>>>>
>>>>>>> - Beth
>>>>>>>
>>>>>>>
>>>>>>> On Jun 16, 2013, at 6:45 AM, Steve Swinsburg
>>>>>>> <steve.swinsburg at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Well if it stays an indie then it becomes super confusing since the
>>>>>>>> version will at some point probably not line up with the reast of
>>>>>>>> the actual
>>>>>>>> 2.10 projects. I discussed this in my proposal, ie purepoms at
>>>>>>>> 2.8.9 or
>>>>>>>> something when the Sakai release is 2.8.2 and other apps at 2.8.6.
>>>>>>>> Head
>>>>>>>> explosion.
>>>>>>>>
>>>>>>>> So it depends if you want to have off cycle release. If not and it
>>>>>>>> is
>>>>>>>> all to be rolled into the main release cycle then go for it.
>>>>>>>>
>>>>>>>> Was there any discussion on my proposal at the conference?
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Jun 16, 2013 at 2:26 AM, Charles Severance <csev at umich.edu>
>>>>>>>> wrote:
>>>>>>>> I figure no time like the present...
>>>>>>>>
>>>>>>>> Of course I would need to fix target versions in JIRA - but that
>>>>>>>> would
>>>>>>>> be easy enough - there are only a few - so I could fix those by
>>>>>>>> hand once I
>>>>>>>> got a 2.10 tentative version.
>>>>>>>>
>>>>>>>> Thoughts / comments??
>>>>>>>>
>>>>>>>> /Chuck
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai2-tcc mailing list
>>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sakai2-tcc mailing list
>>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sakai2-tcc mailing list
>>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai2-tcc mailing list
>>>>>> sakai2-tcc at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>>
>>>>
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>>
>
>

More information about the sakai2-tcc mailing list