[cle-release-team] Good news everybody!

[Matthew Jones]

Good news!

All of the 2.9.0-b03 INDIES are released. I also didn't have to scrap the
b03 release as announced (yesterday?) because changing the maven plugin
didn't fix the problem. Instead, I updated all of the parent poms to point
to a stable master.

We can't make a general announcement yet because the Sakai Core is not
released nor is the .tgz/.zip available for QA servers. This happens with
the old process and outside of Jenkins. I *think* it just involves the old
instructions with the sakai-artifact-maker/tagbuilder but I haven't run
these yet. Some of these instructions are out of date because more projects
(like samigo) are indies now, so the signing is done on Jenkins. The entire
process with indies is basically entirely new.

https://confluence.sakaiproject.org/display/~arwhyte/Generating+a+Sakai+CLE+2.x+release


It's very likely these scripts can be done on Jenkins Jobs. Anyway, I'll
talk to Chris and do this for sure on Monday since this is a process that
has a working automated process (the old build process)

Some other things that need to happen.
1) Most documentation is out of date including the release order:
https://confluence.sakaiproject.org/display/REL/Indie+release+order
The order there has ~24 steps The current order is about 10 (Each group is
listed in this yaml under oXX in the order it needs to be released)
https://source.sakaiproject.org/contrib/cle-release/scripts/jenkinsrelease/tools.yaml

2) Some other projects can probably become indies easier for the 2.10
release
3) We could use a better way of defining versions that "I'm" not releasing
in the future. I'm assuming that maybe Zhen, Chuck Hedrick, Steve
Swinsburg, etc may want to release tools. We need a way to know what the
latest version is to pick up in the release.
  I'm happy keeping it in this yaml file. Any better ideas? Maybe a text
file on confluence?
4) The process for what settings and what configuration needed was pretty
confusing to me. What things do you need to check on the job configuration
for this to all work? I need to test this a little more and make sure the
"clebuild" script adds the right values to the Jenkins xml if it doesn't
exist. This cost a lot of time.

What this meant is in the interim while artifacts were being generated
(about 5 hours today) many artifacts were unavailable if you weren't using
the 2.9.x-all release. In future releases, I can schedule to do these in
smaller pieces to eliminate this problem window.

However I think that leaving it on a stable version, the same as was in
2.8.x, as Steve suggested yesterday is the best idea. Each project will be
a snapshot, but the dependencies should only be on api's, and these are
frozen, so whether a project has a dependency on kernel-api
1.3-SNAPSHOT or 1.3.0-b03
shouldn't matter. The correct kernel is still getting deployed, and the
work that Aaron did moving the kernel utils should have moved the important
stuff out of each project. (At least I think this happened)

Ideally we would have separate versions for api and impl incase your
project did have a dependency on the impl or something that did change from
another project. A tool developer can always override it with a local
dependency management similar to what was done when purepoms existed.

If there is a strong desire or some reason I'm missing to flip master back
to a SNAPSHOT in every indie, please discuss it here. The actual process is
quick, but if we have to do it what it means is that indie tool developers
(like possibly LessonBuilder Team, Samigo Team) won't be able to release as
easily when they want to.

In other news, purepoms is gone as of b01 from 2.9. I'm not planning on
releasing any more purepoms. This significantly simplifies the release
order and really only confused me (which one do I use). Master ONLY defines
versions so you can override these just the same as before if you want.
There are no hard dependencies in master (except against kernel which
everything needs). This change was done in
https://jira.sakaiproject.org/browse/SAK-21564.

Even better news is that they are all in the maven central repository now
too, and they were all released by Jenkins, though it wasn't automatic. I
believe the release problem (aside from documenting it) is 90% solved at
this point. We should be able to get releases out much faster with less
work.

[1]
http://collab.sakaiproject.org/pipermail/cle-release-team/2012-March/000352.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20120316/eb877425/attachment-0006.html