[sakai2-tcc] 2.7.1: indie release handling

[Anthony Whyte]

sakai-2.7.1 is on the launch pad.  However, before I call a vote to release I'd like the TCC to weigh in on whether or not we need to release a number of indie projects for 2.7.1 for which there have been no code changes required for 2.7.1.  The projects in question are: basiclti, emailtemplateservice, jsf, jobscheduler and sakai-mock.

I want to keep answers to this question scoped as narrowly as possible: the issue is not what we should do in the future (David, Matt, Chuck and I have been talking about how to improve our  handling of dependencies in general and our use of Maven in particular) but what I shall do in the next 16 hours or so.

sakai-2.7.1 will deploy the following new indie releases, all generated as the result of maintenance work:

http://confluence.sakaiproject.org/display/REL/sakai-2.7.1

common-1.0.4
edu-services-1.0.6
entitybroker-1.3.15
msgcntr-2.7.1
polls-1.3.8
profile-2.7.3
profile2-1.3.10
purepoms-2.7.8
samigo-2.7.1
search-1.2.6
sitestats-2.1.5

In addition 2.7.x/2.7.1 currently deploy the following indie releases, unchanged since the release of 2.7.0 in June.

basiclti-1.0.3 (imsblti.war bundles up kernel-util-1.1.8.jar and entitybroker-util-1.3.13.jar)
emailtemplateservice-0.4.4 (emailtemplateservice-tool.war: no Sakai-specific jars are bundled up)
jobscheduler-2.7.4 (scheduler-tool.war bundles up kernel-util-1.1.8.jar)
jsf-2.7.5 (jsf-resources.war: no Sakai-specific jars are bundled up)
sakai-mock-2.7.2 (no webapp *.war)

None of these projects have fixes required for 2.7.1.  However, each of these projects' <parent> pom is purepom-2.7.7 and they inherit kernel-1.1.8 and, in the case of basiclti, entitybroker-1.3.13 as dependencies.  On the classpath this is not a problem since each project will pick up the latest kernel and entitybroker api and component jars.  However, in certain cases the webapp *.war artifact includes earlier versions of kernel-util and or entitybroker-utils.  Again, this should only be a concern from a release/deployment standpoint if, for example, kernel-util has changed in fundamental ways between 1.1.8 and 1.1.9.

Below are the util changes that were released with kernel-1.1.9:

kernel-util changes 1.1.8 -> 1.1.9
http://jira.sakaiproject.org/browse/KNL-375

http://jira.sakaiproject.org/browse/KNL-540

http://jira.sakaiproject.org/browse/KNL-489

None of these KNL issues appear to me to releasing any of the above projects on the basis of kernel-util-1.1.9 changes in order to bundle up the latest kernel-util jar.  The same goes for  entitybroker-utils changes (indeed there have been no entitybroker-utils changes in the 1.3.x branch since r75967, 9 April 2010). 

Personally, I do not think we need to generate new releases in such cases. 

However, I am aware that there are some/many folks who believe that our code is simpler and easier to understand (as well as patch) if our general and maintenance releases deploy a single set of kernel and other Sakai-specific dependencies. 

I stand ready to modify the base pom of these projects, increment the <parent> version to 2.7.8 and release each.  The operation is trivial and all 5 projects can be released in under 1 hour.

How would you proceed?

Cheers,

Anth



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100817/06625a24/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100817/06625a24/attachment.bin