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

[Steve Swinsburg]

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-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/01712c52/attachment-0006.html