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

Steve Swinsburg steve.swinsburg at gmail.com
Tue Jun 18 05:49:03 PDT 2013 

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130618/9f2cde5e/attachment-0001.html

More information about the sakai2-tcc mailing list