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

Tue Jun 18 05:23:05 PDT 2013

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