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

Aaron Zeckoski azeckoski at unicon.net
Tue Jun 18 05:53:31 PDT 2013 

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
>>>
>>
>



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

More information about the sakai2-tcc mailing list