[cle-release-team] Status of release . . .

[Matthew Jones]

That was kind of what #4 was referring to. However there are some 30 tools
that would need to have their parent poms modified and committed every
time, either manually or automatically with a script. Not a very hard task
or a script to write one (and Chris might already have this) but I was
hoping to just handle it during the release. We can manually bind
everything to a stable master just as we did with a stable purepoms just
the same. The master (2.9.0-b03) is successfully released and in the
repository, I just haven't updated every parent of every indie yet, hoping
that this could this plugin could release it then put it back to SNAPSHOT.

We *could* decide to leave the parent on the last released master, however
then the project would have to override the dependencies management on the
dependencies it needed, just like it used to do, however all of these were
removed by https://jira.sakaiproject.org/browse/SAK-21564 because we
expected this to work, and that jira would need to be partially reverted if
we were to decide to do what you're suggesting. I was hoping the release
plugin could switch the parent to a released master, tag it, release it,
then switch it back. It would be wrong for a few seconds but that should be
acceptable once every few weeks.

Purepoms defined no versions and required each individual tool to keep
their versions up-to-date. master defines all versions (including snapshot)
so tools don't have to do anything. This is the problem.

The release plugin seems to have no problem updating dependencies whether
they're in dependencies or properties, but it has the bug so it can't
update the parent. Updating the parent seems to be a never-ending issue
with maven that's completely annoying (
http://jira.codehaus.org/browse/MNG-624 ).

On Thu, Mar 15, 2012 at 1:14 AM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> Hmm, that sounds very fragile.
>
> Up until now, all branches bound to a stable parent version and these
> don't/shouldn't change that much. This was the case with purepoms anyway.
>
> So profile2-1.4.x currently has parent:
>
> <parent>
> <groupId>org.sakaiproject.purepoms</groupId>
> <artifactId>sakai-commons-tool</artifactId>
>  <version>2.8.4</version>
> </parent>
>
> Profile2-1.5.x binds to a snapshot of master but that should probably be
> released and stabilised:
>
> <parent>
> <groupId>org.sakaiproject</groupId>
> <artifactId>master</artifactId>
>  <version>2.9-SNAPSHOT</version>
> </parent>
>
> Anyway, it probably isn't a lot of extra work just ensuring the branches
> are bound to stable parent versions as that is what's happened for a while
> anyway. There is a point where automating everything can be disastrous and
> difficult to untangle when things go wrong. I'd be much more comfortable
> with ensuring my code is ready to go, then pressing a button to get the
> release done.
>
> We use jenkins here at ANU to create releases. The process is exactly as
> above: the developer gets their code ready, then we just press the button
> and fill out the versions and queue them all up. We have about 20 portlets
> which we do in this manner, it doesn't end up being a lot of work in the
> end, and means we retain control over anything that might go wrong - there
> are so many moving parts in a release: commits, file deploys, etc.
>
> For the CLE release, can't we release just master as some version, update
> projects to bind to it, then release the projects?
>
> cheers,
> S
>
>
> On 15/03/2012, at 3:43 PM, Matthew Jones wrote:
>
> So I thought after I got kernel and master released, I'd have clear
> sailing. However that's not the case.
>
> I tried 48 releases with different parameters and settings and none of
> them worked. The biggest issue is the parent version. I can't get the maven
> release plugin (when you're doing mvm release:perform) to update the parent
> version.
>
> - Normally what the release plugin does is
> - Update the Snapshots
> - Commit the non snapshots back
> - Tag this branch
> - Update the versions back to snapshots
> - Commit this back
>
> The only issue I can find is this one where it says parents with SNAPSHOTS
> aren't updated. There's a patch attached but not applied to Maven
> http://jira.codehaus.org/browse/MRELEASE-449
>
> All I should have to do is pass
> "-Dproject.rel.org.sakaiproject:master=2.9.0-b03
> -Dproject.dev.org.sakaiproject:master="2.9-SNAPSHOT" and it should version
> this just like everything else.
>
> If you run mvn release:prepare on the command line, it asks you if you
> want to change it, but doesn't actually change it.
>
> Some other ideas I tried:
>
> 1) Using mvn versions:update-parent -DparentVersion="[2.9.0-b03]"
> release:prepare . . .
>  . . . This DOES update the parent version, however the release:prepare
> won't commit back the modified pom.xml, and there's also no automatic way
> to update the parent back to snapshot aftre so that's mostly out of the
> question
>
> Some other ideas I didn't try yet:
>
> 2) Applying the patch on this ticket and using a custom version of the
> release plugin
> . . . This looks like it would work, I didn't try this yet
>
> 3) Configure Jenkins to run pre-build and post-build steps to update the
> parent version
> . . . However there's a comment on the M2 release plugin page that you
> can't use the pre and post steps when using this plugin (
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin?focusedCommentId=58001814#comment-58001814
> )
> . . . But if I'm firing it from a separate job I think I can still get
> these steps to run.
> . . . Maybe there's a better plugin that can make this action happen?
> . . . However it really needs to run before, wait until release is done
> then run again, so this probably won't work
>
> 4) Writing some custom code into the release script which performs this
> outside of Jenkins for now
> . . . This would be the easiest, it would basically just do a svn co all
> the indie branches, update the poms and commit
> . . . We wouldn't want to use this for long
> . . . I could probably just do this manually tomorrow
> . . . But the branches for 2.9.x won't be usable unless these are also
> branched and then the scm tags in the XML updated (Because you can't
> actually pass these in as paramters
> http://jira.codehaus.org/browse/MRELEASE-128)
>
> The best deal would be if the release plugin can just do it all. It's
> really disappointing that this all doesn't work and causes a TON of extra
> work because of the unresolved issues.
>
> Anyone have a #5 idea? :)
> _______________________________________________
> 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/20120315/552820c5/attachment-0006.html