[sakai2-tcc] 2.7.1: indie release handling

[David Horwitz]

-1 for releasing these its unessasary

On 08/17/2010 11:38 PM, Anthony Whyte wrote:
> 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
>
>
>
>
> _______________________________________________
> 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/20100818/ba4ac4af/attachment-0001.html