[sakai2-tcc] Proposal: eliminate all indies, re-version trunk to CLE 4.0
Anthony Whyte
arwhyte at umich.edu
Tue Jun 18 05:16:30 PDT 2013
It can just as easily be 2.10. However, if we increment the minor version by 1, messagecenter which is currently versioned 3.0-SNAPSHOT, will either need to be treated as an exception (yuck) or we will have to change its <artifactId> to something other than "msgcntr" to version it 2.10. [1] There was interest expressed at the San Diego meeting with jumping to 4.0, especially if dashboard helped evolve the user experience. Steve sums up the other reasons well and Alan lays out the case for "cool."
I expect someone might scream about this and declare it a stupid idea. I myself even expressed reservations during the San Diego meeting. But Beth liked the idea so I added it to the proposal.
For me, what's important is working towards a simplified build. If 2.10 makes more sense than 4.0 than fine (just need to decide what to do with msgcntr). I don't want the proposal to founder on two integers separated by a decimal point.
Anth
[1] https://source.sakaiproject.org/svn/msgcntr/trunk/pom.xml
<groupId>org.sakaiproject.msgcntr</groupId>
<version>3.0-SNAPSHOT</version>
<artifactId>msgcntr</artifactId>
On Jun 18, 2013, at 8:05 AM, Berg, Alan wrote:
> 4.0 is in balance with the stability and maturity and aspirations of the product. Plus all the cool uses emerging in Sakai Land. It is a well deserved sign of proven confidence and increasing delivery.
>
> Regards,
> Alan
>
>
> Alan Berg
>
> Innovation working group
> On the use of ICT in Education & Research
> University of Amsterdam
> From: sakai2-tcc-bounces at collab.sakaiproject.org [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Steve Swinsburg [steve.swinsburg at gmail.com]
> Sent: 18 June 2013 14:01
> To: May, Megan Marie
> Cc: sakai2-tcc Committee
> Subject: Re: [sakai2-tcc] Proposal: eliminate all indies, re-version trunk to CLE 4.0
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130618/9afc45d7/attachment-0001.html
More information about the sakai2-tcc
mailing list