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

Matthew Jones matthew at longsight.com
Thu Mar 15 10:59:46 PDT 2012 

Okay forget all of this. I believe that the problem is that master was
using an ancient version of the release plugin (2.0-beta-9) and kernel was
using an old version (2.1). I think the changes for fixing the parent have
actually been incorporated by other jiras so I'm going to upgrade and try
this out.

The only problem is that I'd already released the master for b03 to maven
central, and there's no taking that back, so b03 has to be scrapped and we
move onto b04! Progress right!? ;)

On Thu, Mar 15, 2012 at 8:31 AM, Maurer, Christopher Wayne <
chmaurer at iupui.edu> wrote:

>  Yeah, when I was tinkering with scripts, I ran into the same thing with
> the prepare goal.  Couldn't figure out why it didn't update the parent
> version like I wanted it to.  The way around it is to create a "temporary"
> branch.  The release:branch goal DOES work to update the parent version.
>  So, you'd branch all the modules, updating the parent to the correct
> version, then release from that branch.
> So the script that I was working with took an externals and just iterated
> through everything in it, doing this:
> mvn --batch-mode release:branch -DbranchName=${NEXT_TARGET_FOLDER}
> -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
> -Dproject.rel.org.sakaiproject:master=${MASTER_VERSION}
> -DscmCommentPrefix=${SAK}
>
>  Not sure if creating an additional branch would work out with the scheme
> you are putting in place since the location changes of the release base
> changes each time.  But might be worth a shot.
>
>  I forget if it ever worked for a parent version, but you could also try
> the versions plugin.  I think you can give it the full group and artifact
> of the thing you are changing.
>
>  Chris
>
>   From: Steve Swinsburg <steve.swinsburg at gmail.com>
> Date: Thu, 15 Mar 2012 17:17:11 +1100
> To: Matthew Jones <matthew at longsight.com>
> Cc: <cle-release-team at collab.sakaiproject.org>
> Subject: Re: [cle-release-team] Status of release . . .
>
>   Ok so it probably needs to be a separate process to update the parent
> versions in the tools as required, then release them via jenkins.
> At least that would be the workaround until the release plugin can do it
> (which may be never)!
>
>  cheers,
> s
>
>
>
>  On 15/03/2012, at 4:43 PM, Matthew Jones wrote:
>
> 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-21564because 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
>>
>>
>>
>
>   _______________________________________________ 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/711addeb/attachment-0006.html

More information about the cle-release-team mailing list