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

Bryan Holladay holladay at longsight.com
Tue Jun 18 05:41:31 PDT 2013 

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/027e53f2/attachment-0001.html

More information about the sakai2-tcc mailing list