[sakai2-tcc] LTI Release Consulting

[Hedrick Charles]

On Feb 25, 2013, at 6:29:08 PM, Charles Severance <csev at umich.edu> wrote:

> Hi all,
> 
> I need a indie release consultant for LTI.   I want to come up with a really nice LTI 2.1 release - release notes, etc.
> 
> I love Indie releases because we can do them off-cycle but really, I want to release a tag for LTI  2.1 for Sakai 2.8.3, 2.9.0, 2.9.1, and 2.9.x (to become 2.9.2) where *I* test the tags / artifacts for each of those Sakai tags rather than just telling folks to edit the pom.xml and fix little weirdnesses that comes up.
> 
> I looked at the branch/tag/artifact naming pattern for two of our leading lights in the Sakai indie world (Profile2 and LessonBuilder).  Profile goes pure-indie with its own versions and a compatibility map and other wonderful stuff here:
> 
> https://confluence.sakaiproject.org/display/PROFILE/Profile2
> 
> Does this mean that the binary artifacts work without change the the "compatible Sakai versions" in the table?   For source, do they need pom.xml tweaks and how does Steve communicate any necessary pom.xml tweaks for source folks.
> 
>  LessonBuilder kind of goes back and forth in branch and tag naming between things that mention the LB version and the Sakai versions in the tag folder:
> 
> https://source.sakaiproject.org/svn/lessonbuilder/tags/

Lessons has a separate version number. I've considered changing that.

> I wonder if this means tags like "recommended for 2.9.0" change over time?

No. "recommended for 2.9.0" is historical. It means that tag that should have been released with 2.9.0. For both 2.9.0 and 2.9.1 there were a couple of key patches that I would have preferred be in the release, but were too late to be included under the rules. 

Any version of lessons should work fine with any 2.8.x or 2.9.x, and with minor changes with 2.7.x. I anticipate supporting 2.9 - 2.10 with the same code.

At one point I did a tag with a Lessons version number (e.g 1.3) when I got to a point that I thought was stable and worth a "release." But that was before Lessons was included with the core, and was widely tested by people outside Rutgers. At this point the best testing seems to be done right before a Sakai release, so if someone wants a particularly well tested version, I think they should use the one that is associated with one of the sakai releases. That means the most recent "recommended" tag. At this moment my recommendation is the 2.9.1 tag, no matter what version of Sakai you are using.

> I would like something that worked nicely with both source and binary adopters and to be explicit in connecting Sakai versions and BLTI versions in something other than release notes.  I of course am one of the *least skilled* amongst this group as an actual deployer of Sakai in production - so if you tell me that my ideas below are crazy and too over thought - that is OK.  Simpler is better - but I crave explicitness.
> 
> I am thinking something like this:
> 
> /branches/basiclti-2.1-x
> 
> /tags/basiclti-2.1.0-sakai-2.8.3 
> 
> /tags/basiclti-2.1.0-sakai-2.9.0 
> 
> /tags/basiclti-2.1.0-sakai-2.9.1
> 
> I would also name the binary artifacts version in the poms in each of the tags something like "basiclti-2.1.0-sakai-2.9.1" - if the 

That's the form I use, more or less. 2.9 binary artifacts are generated automatically by the normal Sakai processes, so I don't do anything about them. For 2.8.x I build a binary for each Sakai release, e.g. 

sakai-lessonbuildertool-assembly-1.4.1-r116229-2.8.1-tomcat-overlay.zip This is the tag sakai-lessonbuildertool-2.9.0-recommended.
sakai-lessonbuildertool-assembly-1.4.2-r119876-2.8.1-tomcat-overlay.zip This is the tag sakai-lessonbuildertool-2.9.1-recommended.

I include the specific revision number, since sites that simply fetch trunk will probably be using revision numbers to keep track of what they have. 2.8.1 means it was built using 2.8.1 binaries for dependencies. It should be appropriate for any 2.8.x version.

> I would make the tags from the branch, and immediately tweak only the pom.xml and any tweaks necessary to work with 2.8.3 (or whatever).  Then the moment I like the tag, I freeze the tag forever and once I announce it I never change it.  If something was wrong with that tag, I would make a new one with a name like:
> 
> blti-2.1.0-sakai-2.8.3-01
> 
> I know it is kind of long and verbose - but I want something that works with the externals of all the various versions that we support and I think that we indie builders have the responsibility of supporting and testing known and precise tags of our indie releases with the currently supported Sakai releases.  It is like encoding Steve's table in tag form, taking Chuck H's approach and formalizing it a bit.   For example if you look here:
> 
> https://source.sakaiproject.org/svn/lessonbuilder/tags/sakai-lessonbuildertool-2.9.0-recommended/
> 
> There is also a file named "pom.xml.281" which I assume is the pom tested with 2.8.1
> 
> I would rather just make more tags and give people a precise artifact that is exactly suitable for purpose and named in a way to make things *really clear".
> 
> I think that over the next few years, the pace of Sakai 2.x releases may slow and it may be more important to evolve indies faster than the core Sakai release.  I am not sure this will happen, but I would like to be prepared for it.  In particular, LTI will evolve a good bit over the next 18 months - what we have now is LTI 1.1.  There is LTI 1.2, 1.3, 2.0, and 2.1 in the pipeline already - so I could have easily 2-3 major functionality releases of LTI over the next 12 months so I want to come up with a way to reduce the loose linkage.

If point releases slow I may need to decouple Lessons releases from Sakai releases again. At that point I'd probably start doing my own tagged "releases" again. A lot depends upon how QA is being done.

> 
> Part of my crazy effort on LTI the past few weeks is to get it all nice and clean so I can start working on LTI 2.0 in the May/June timeframe.
> 
> Thoughts / comments welcome..
> 
> /Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130225/52da7fb6/attachment.html