[cle-release-team] Versioning JIRA components

Mon Mar 18 20:28:15 PDT 2013

I would not wait for a 4.0 mega-move to commence re-versioning.  At a minimum I would expand the list to include the following modules and target trunk and 2.9.x as soon as 2.9.2 hits the streets.  I recommend extending the re-versioning effort to 2.8.x as well (it will simplify Jira project consolidation). 

Re-version targets

common
edu-services
entitybroker
emailtemplateservice
hybrid (recognizing of course that it might be dropped from the build)
kernel
mailsender
polls
search
shortenedurl
sitestats
webservices

Yup, I've included the kernel.  I see no compelling reason to hold off re-versioning it too.   

This leaves the following projects untouched (for the moment):

2.9.x
basiclti (2.0.2-SNAPSHOT)
contentreview (2.9.4-SNAPSHOT)
lessonbuilder (1.4.2-SNAPSHOT)
messagecenter (3.0.2-SNAPSHOT)
profile2 (1.5.2-SNAPSHOT)

2.8.x
basiclti 1.3.7-SNAPSHOT
contentreview 2.8.9-SNAPSHOT
messagecenter 2.8.5-SNAPSHOT
profile2 1.4.12-SNAPSHOT

I'm tempted to add profile2 and basiclti to the list too; in the case of basiclti since Chuck is on the verge of a 2.1 release its probably best to leave it off the list at present, although it should be noted that one can use the release plugin to generate a new branch with updated version numbers in seconds.  Changing a version is trivial; communicating the change outwards perhaps less so.

Indies were/are an attempt to shorten in a targeted manner--i.e. via individual modules--the long release cycles that have marked the history of the CLE.  Leveraging the Maven release plugin, the goal was to provide teams with a simple, repeatable and well-understood mechanism for automating and standardizing the release process [1].  This approach has proved its worth on a number of occasions.  However, it must be admitted that the indie approach has never truly caught fire with the community--only Swinsburg, Horwitz, myself and Jones (reluctantly) have really leveraged the indie release mechanism to full effect.  Nor has it ever been fully implemented leading to inconsistencies in module behavior as far as build deployment and release handling is concerned--which is one reason I created sakai-trunk-all back in the day.  While I find it easy to comprehend and manage the various independently versioned modules that comprise a CLE distribution others find it confusing and occasionally baffling.  Indies have also complicated our issue tracking process (thanks Jira), forcing us to create additional projects and injecting unnecessary complexity into issue reporting and tracking.

I think it's time to shorten our lines and embrace opportunities for simplification, whether in the code or in our practices.  So long as we stay committed to shorter release cycles, re-versioning the modules listed above is an opportunity to commence simplifying our builds, releases and bug tracking with little downside.  I can make myself available to assist in the effort.   

Cheers,

Anthony

On Mar 18, 2013, at 5:38 PM, Sam Ottenhoff wrote:

> Do others think it makes sense to do this a few chunks at a time, or should we wait for someone to propose the mega-move to 4.0?
> 
> My proposal from last week's call was to move Search, Polls, Mailsender, and ShortURL back into the main SAK project... I believe they should all have versions < 2.9 so they could lose their indie status without versioning problems.  
> 
> --Sam
> 
> 
> On Thu, Mar 14, 2013 at 12:23 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> 4.0.0? What about the build number? 4.0.0.0 at least.
> 
> On a more serious note, I think we should probably take it in steps
> but it maybe getting a few of these squished back into the main core
> would be a good starting point (current versions be damned).
> 
> -AZ
> 
> 
> On Thu, Mar 14, 2013 at 12:09 PM, Noah Botimer <botimer at umich.edu> wrote:
> > Doesn't this all boil down to an incomplete modularization? We said somewhere along the line that a bunch of things were going to fly solo and version themselves, and that there were teams that wanted this responsibility/flexibility.
> >
> > As far as I can tell, we've only really treated Profile 2 and LTI like that (where the team motors on and tells us what minor version should be packed for a given release, and we're not [CLE team, MT, core people, whatever] left to track more disparate things and check more boxes). Everything else just revs with the core releases (maybe msgcntr and lessonbuilder are between worlds) and folks like Sam are left holding the bag and cleaning it all up.
> >
> > Without a reasonably centralized, authoritative, and browseable map of dependencies between a core release version and modules, this is all just too much work. I do not consider 376 POM files to be worthy of any of the above adjectives.
> >
> > I think we have to decide which world we want to live in and make it happen. Either there are module owners who rev and pin their module version to the next release or there aren't. Nearly a hundred core modules living at some unknown point on that spectrum with no decent tool to manage it is a bankrupt position.
> >
> > I personally think we should declare module bankruptcy, fold 90% of our stuff together, version it 4.0.0, and have a barbecue. There will be plenty of recoverable salary dollars to have quite a party.
> >
> > Thanks,
> > -Noah
> >
> > On Mar 14, 2013, at 11:43 AM, Aaron Zeckoski wrote:
> >
> >> Yeah, I don't see any way to version components in our JIRA either...
> >> Looks like it isn't coming soon either
> >> -AZ
> >>
> >>
> >> On Thu, Mar 14, 2013 at 11:36 AM, Sam Ottenhoff <ottenhoff at longsight.com> wrote:
> >>> On the call this morning, it was mentioned that JIRA components could now be
> >>> versioned separately.  For example, a "Polls" component could be marked as
> >>> Fixed for 1.4.0 while a JIRA with "Assignments" component could be marked as
> >>> Fixed for 2.9.0.
> >>>
> >>> I still see this as an Open feature request in the Atlassian JIRA:
> >>>
> >>>  https://jira.atlassian.com/browse/JRA-3501
> >>>
> >>> Does anyone know differently?
> >>>
> >>> --Sam
> >>>
> >>> _______________________________________________
> >>> cle-release-team mailing list
> >>> cle-release-team at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >>>
> >>
> >>
> >>
> >> --
> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> >> _______________________________________________
> >> cle-release-team mailing list
> >> cle-release-team at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
> 
> 
> 
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130318/50baa403/attachment-0006.html 