[sakai2-tcc] 2.7.1: indie release handling

Wed Aug 18 09:00:41 PDT 2010

I believe some of this is build paranoia, and nobody ever wanting to
accidently hitting a RunTimeException because of incorrect dependencies. Our
environment at Michigan has a lot more people from operations and management
wanting a lot of testing, verification and sign-off on every release. If I
was siding on the side of paranoia, I wouldn't be happy with this unless
both util jars were identical, or it could be proved that what was different
in them wasn't code related.

In our local source builds for ctools, we do a full rebuild of everything
and reversion every project on nearly every release. This gives a pretty
high level of confidence that things are changed and the correct code is
getting picked up. I don't like it, but I haven't had the time to really fix
it.

I'd posted a few months ago about this problem that Anthony mentioned with
very little response. [1]

You can say these artifacts *should* be the identical, but the file sizes
are different, which is enough cause for a 'little' paranoia. This was just
one example.

Basiclti 1.1.0-rc01 kernel-util-1.1.1

http://source.sakaiproject.org/maven2/org/sakaiproject/basiclti/basiclti-pack/1.1.0-rc01/
   235139  03-22-10 12:39   WEB-INF/lib/sakai-kernel-util-1.1.1.jar
But in
Basiclti 1.0.0-b01 is is kernel
1.1.0-util-beta04http://source.sakaiproject.org/maven2/org/sakaiproject/basiclti/basiclti-pack/
   236038  01-21-10 00:31   WEB-INF/lib/sakai-kernel-util-1.1.0-beta04.jar

There really are 3 major parts to the kernel that some tool is likely to
include:

org.sakaiproject.kernel -> sakai-kernel-api
org.sakaiproject.kernel -> sakai-component-manager
org.sakaiproject.kernel -> sakai-kernel-util

I know for api, we've taken the stance that no changes are allowed, and if
there was a change without a tool update there would be some
RunTimeException. We should do the same for kernel util and component
manager and lock them for the entire major to 1.0, 1.1, 1.2, etc as
mentioned.

So the jars will always be packaged as
sakai-kernel-util-1.0.jar and depend on 1.0, 1.1, 1.2. A new kernel minor
can obviously be deployed to components.

I understand that this problem isn't something that can be fixed for this
build. So saying that, I would probably also lean on the side of
re-assurance and do a rebuild/re-release of everything for 2.7.1, even
though it *very likely* (99%?) won't be an issue until we can fix some of
this. When I threw out the 99% number in a meeting a few weeks ago, nearly
everyone just said 'do it' just incase so we're 100%! :)

[1]
http://collab.sakaiproject.org/pipermail/sakai-dev/2010-March/006544.html

-Matthew

On Wed, Aug 18, 2010 at 9:49 AM, Beth Kirschner <bkirschn at umich.edu> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20100818/39bdc9d6/attachment-0001.html 