[sakai2-tcc] 2.7.1: indie release handling

[csev]

I am gently for the rebuild.   

Not because of 2.7.1 per se - but because of the kernel release.  These don't depended on sakai itself but they *do* depend on the kernel - if the kernel is revved, we should rev these.

If we do a 2.7.2 without a kernel release then they should not need to be released.

I am on the fence and could be swayed.

/Chuck

P.S. Anthony - this is very well said - probably should turn this into a blog post or some other document - it is the most articulate summary of the intricacies of our dependency tree that I have heard.

On Aug 18, 2010, at 9:49 AM, Beth Kirschner wrote:

> I'm on the fence for this one, though leaning toward bundling a new  
> release for these indie projects. I know you want to scope this  
> question narrowly, but I wonder if reviewing kernel changes and  
> objectively determining whether or not the dependency is relevant and/ 
> or picked up by the JVM classpath is a scalable process.
> 
> - Beth
> 
> On Aug 17, 2010, at 5: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-375http://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
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
>