[cle-release-team] Versioning JIRA components

Mon Mar 18 20:52:14 PDT 2013

I think Anthony's extended list is fine.

I wouldn't do this for 2.8 though, too disruptive and the release process
isn't that long anymore now the process has been sorted (and someone close
to the repo does the indies)
https://confluence.sakaiproject.org/display/~steve.swinsburg/sakai-2.8.3+release

I say all this with a caveat: If we drop the indies and their potentially
rapid release cycles, we need to have more rapid full Sakai maintenance
releases (and if the process is simpler and quicker than it is now, I will
do them). We cant wait months between releases. If we do we are back to
where we started, releases will be stale and people will run from the
branches.

cheers,
Steve

On Tue, Mar 19, 2013 at 2:28 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

> 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
>
>
>
> _______________________________________________
> 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/20130319/c0c3e3ee/attachment-0006.html 