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

Steve Swinsburg steve.swinsburg at gmail.com
Thu Mar 15 20:38:09 PDT 2012 

Wow, what a pain.

I think releasing master, then updating the indies to bind to that will be fine. Then if projects want/need to bind to updated versions of libraries they can update the master version which handles that, or override them locally if there is no master yet. I think that is feasible?

cheers,
Steve


On 16/03/2012, at 1:34 PM, Matthew Jones wrote:

> Okay, I spoke too soon. Upgrading the release plugin does half make this work to update the parent, however it only works in interactive release mode (where it asks you questions about which version to release) on the command line OR if you define a properties file and specify all of your dependency resolution.
> 
> https://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html 
> 
> For instance locally when I have
> dependency.org.sakaiproject\:master.development=2.10-SNAPSHOT
> dependency.org.sakaiproject\:master.release=2.9.0-b03
> 
> It works, however, there is no way to automatically detect these OR provide them via a command line when running in batch mode. I found this as another outstanding bug: http://jira.codehaus.org/browse/MRELEASE-548 
> 
> And the Maven Release Plugin doesn't allow you to specify the release.properties file, or change anything to this directly.
> 
> The sample project I had finally deployed after 62 attempts ( http://builds.sakaiproject.org:8080/view/CLE%20contrib/job/cle-release-sample/62/ ) This was only after manually changing the parent version, committing it and changing it back when the release was done.
> 
> So . . .
> - While getting those options to be used from the command line by the release plugin would be nice, I don't think that really is a realistic option.
> - It might be possible to have a Pre-Build Step in Jenkins create the release.properties file and it would be able to use that
> - We could manually just update the parent version forever and/or just leave it static
> - We could forget about doing the release on Jenkins as the number of issues with the maven release plugin and the jenkins release plugin is just too much to work around without additional development for our build process?
> 
> For this build though I think we should just go with Steve's suggestion. I can change every 2.9.x indie's parent version to "2.9.0-b03" and then commit.
> 
> We may want to just leave it like this and just manually (or semi-automatically update it) on the next release, this was kind of what purepoms did according to him. 
> 
> The downside of this is that then all of the 2.9.x indies won't pick up new versions of their dependencies unless that version was included in their local pom. This was all removed as part of Noah's cleanup.
> 
> Or we could just revert it back to 2.9-SNAPSHOT after the all the indies are deployed, which would have a period of time where the indies were slightly out of date.
> 
> As suggested on the call this morning, we could also branch all of the indies and do this, updating the version and the SCM block. But that would also require copying the job an extra job in Jenkins for each of the indies (2.9.x - release), and setting the new patch. That would take at least an hour or so to get right.
> 
> Yea, amazing amount of work just to deal with this parent and these indies.
> 
> Indie tools . . . A great idea revealing so many maven bugs.
> 
> The reason that all of these problems are coming up now is that Chris and Anthony always did this build locally before and we had the "good" idea of trying to save time by distributing the work and getting it up "one button push" on Jenkins. I really don't see that happening without changing that Jenkins plugin or manually dealing with this parent version.
> 
> On Thu, Mar 15, 2012 at 1:59 PM, Matthew Jones <matthew at longsight.com> wrote:
> 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-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
>> 
>> 
> 
> _______________________________________________ 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/20120316/b09369b9/attachment-0006.html

More information about the cle-release-team mailing list