[cle-release-team] Sakai 2.9 release process

Sun Nov 20 16:32:41 PST 2011

I think the basic consensus that came out of last Thursday's call was that
we want to quickly commit anything that will tangibly make our build
process for the 2.9 betas easier.  Our plan is to use nightly builds for
two alpha tags and then to branch and manually release a 2.9.0 beta from
the branch by Dec 15.

We didn't spend a lot of time discussing poms, but I think you have large
support if it leads to a simpler build process.  What's the first major
piece of work you want to tackle?

--Sam

On Sun, Nov 20, 2011 at 7:02 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> I'd like to keep this discussion going as I think it is important to get
> this work done soon and I am prepared to do all of the pom work to get us
> there.
>
> To point out one of the complexities with the current purepoms setup, here
> is a real situation (read: headache and waste of time) I am going through
> right now.
>
> I fixed some bugs in common and need those fixes for a new release of
> Profile2. Here is what was required:
>
> 1. Release common as 1.1.5
> 2. Update 2.8.x/master/pom.xml to bind to common 1.1.5
> 3. Update pure-poms/branches/purepoms-2.8.x/sakai-commons-tool/pom.xml to
> also bind to 1.1.5
> 4. Release purepoms as 2.8.4 (this versioning mixup is also a huge pain,
> purepoms 2.8.4 -> CLE 2.8.2!!!)
> 5. Bind Profile2 to the new purepoms version.
> 6. Release Profile2 1.4.5.
>
> Far too much overhead, confusion and complexity.
>
>
> Steve
>
>
>
> On 17/11/2011, at 5:49 AM, Noah Botimer wrote:
>
> Having thought about this for a while (and done a lot of combing and
> experimenting), I've got a few points as food for thought.
>
> 1. Our use of parents/imports/aggregation is kind of a mish-mash.
>
> 1A. We could readily define dependencies in a parent (instead of just
> dependencyManagement) to simplify the child projects. For provided-scope
> items, any "extra" dependencies are just at compile-time. (So, something
> like gradebook-service-api being available is no problem if you don't use
> it -- no impact on the final artifact.) Then, things like sakai-kernel-api,
> sakai-component-manager, and a list of others that are very common would
> not need to be redeclared everywhere.
>
> 1B. There are other items that are inherited and should be omitted if
> correct for a child module. These include things like repositories, plugin
> repositories, and plugin settings. We have plenty of examples where they
> are replicated down the tree (harmless, but confusing -- until something
> changes, then a lot of work to clean up).
>
> 1C. A module's version is now inherited when using parent, so the items
> that should stay synchronized with the versioning of the parent should not
> specify its own version. It can be specified at any level and it flows down
> from there. (For example, the webservices module does this correctly, e.g.,
> top-level 2.9.0-a02, webservices specifies 1.1.0 => axis inherits 1.1.0.
> Announcements does not, specifying 2.9-SNAPSHOT at each level, the clear
> intention being to inherit [at least from announcement-base, probably
> master]).
>
> 1D. If we don't want to define/use actual dependencies in a parent POM
> (just dependencyManagement), we can explore using an import instead of
> parent. This does require that pieces like the repositories and plugins are
> defined in the not-quite-child, so this would probably be more useful
> outside of the core, say contrib indies, or special cases.
>
> 2. I'm of the mind that a parent POM should be all about simplicity,
> efficiency, and eliminating duplication.
>
> 2A. I would be in favor of condensing the purepoms. At present, they only
> supply dependencyManagement and present four layers of complexity. It was
> an interesting option to choose only the set of dependencies you want, but
> in practice, the provided scope for all of these makes that choice of
> little relevance. (Taking everything doesn't hurt, but maintaining more
> layers does.) These should be defined as dependencies to make the parent
> declaration sufficient to use the libs.
>
> 2B. There is some value in preserving the Sakai convention for
> sourceDirectory and friends (src/java, etc.) for the core projects, but new
> projects should not have to adopt and override this to get back to Maven
> defaults (src/main/java, etc.). There might be an easy way to pull this
> off, but I'm not sure.
>
> 3. I'm in strong favor of condensing entitybroker, commons, and
> edu-services. I agree that the kernel is probably the wrong place for the
> entirety (maybe EB API). But I think this should probably wait for 2.10.
> We're late in the cycle and doing a lot of source moves is bound to disrupt
> the commit continuity. I think a K1-style arrangement for these items as
> the "shared libs other than kernel" is a great project for shortly after
> the 2.9 branch.
>
>
> I wouldn't blame anybody for ignoring this wall of text. So I plan to put
> some things into Confluence, with some references to possible approaches
> I've prepared in contrib. I hope that it will be a structured, summative
> review that can be used to plot our course.
>
> My contrib experiments are here:
> https://source.sakaiproject.org/contrib/botimer/cleanup/branches/
>
>
> Thanks,
> -Noah
>
> On Nov 14, 2011, at 5:16 PM, Beth Kirschner wrote:
>
> I'd like to summarize some recent off-list discussions in an effort to
> move forward the Sakai 2.9 build & release process. But first, I think
> we need to not lose sight of the primary goal, which is to release 2.9
> alpha/beta tags quickly and often. It's now mid-November and this
> release team has not directly released any tag. We've just removed
> several road-blocks to making this happen (thanks all!). I think the
> next steps is that the release team needs to take action, make
> decisions, and start putting out regular tagged releases for QA.
> Additionally, we need to decide on updated milestones for the 2.9
> release, starting with when to branch. I'd like to suggest that we
> discuss _and_ make decisions no later than this Thursday's Release
> Team meeting that will result in the following:
>
> 1) a new alpha tag build started this week
> 2) a target date for the first branch and beta tag
>
> Primary goal: Release 2.9 alpha/beta tags in a timely, efficient manner.
>
> Secondary goals:
> * Clean up the release process enough to automate (at least most of) it
> * Rationalize kernel-util (initial testing of this proved successful)
> * Break calendar/assignments cross-dependency (SAK-21389 - fixed)
> * Break courier/presence cross-dependency (SAK-21397 -patch attached)
> * Rationalize kernel, entitybroker, common, edu-services and sakai-
> basic-tool, sakai-standard-tool, sakai-common-tool, sakai-edu-tool
> * Break awkward versioning/release constraints between kernel/
> framework and indies
> * Explore using a real repository manager and automated build server
> * Balance doing the best possible thing, the smallest possible thing,
> and resources available (avoid partial/piecemeal/long transitions)
>
> Remaining proposed work to achieve the primary goal is as follows:
>
> 1. Move kernel-util to shared.
> 2. Combine the base pom.xml and master/pom.xml into one, perhaps
> called sakai-parent (following the Jasig model for uPortal).
> 3. Possibly remove purepoms entirely, all indies then inherit from the
> sakai-parent pom.
> 4. If not 3, then collapse these into one pom, perhaps called sakai-
> indie or similar.
> 5. Migrate Entity broker into the kernel
> 6. Combine common and edu-services into  a single package
>
> Additionally, we also discussed as a short term way forward to just
> start cutting [alpha] releases based off some revision of nightly.
>
> Say if we wanted the next alpha to be next Tuesday, then what revision
> was Monday midnight (time zone of the source control server so EST)
> that would be the package what is deployed to QA servers. We could
> call next weeks
> sakai-2.9.0-a02-2011-11-15 rXXXXXX
>
> And just go with that until actual release candidates. Once we get
> there, the indie dependency tree won't have any cycles or other
> problems, we shouldn't have to rebuild all of the indies, and make it
> much easier to run the script to pump out a regular release.
>
> The only downside is that regular people if they want the source won't
> be able to check out the alpha tag.
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20111120/00fc2f9f/attachment-0006.html 