Inconsistencies between the poms and the release process.
Locked
 
|
|
On Mon, 2012-05-07 at 12:51 -0400, Nicolas LE BAS wrote:
> It would be great if a JIRA expert > could explain, otherwise I'll just test it soon. Just test i ;-) it's pretty straight forward. Under https://issues.apache.org/jira/browse/TILES go Versions -> Manage Versions -> "3.0.0" -> Release. (Archive is when a version is "gone", that is it doesn't even make sense to report bugs against such a version). > IMHO here's what should happen at this stage: > * close all issues that are marked as "fixed in this version". > * make it impossible to use this version in the "fixed in version" > field for open issues. Yes, although i'm unsure of the latter. It makes sense only when the issue's resolution is "fixed". But what about "duplicate" and "won't fix" etc? And maybe this happens anyway when you release the version? > * tiles.apache.org/framework, but that one has been deployed by > mvn:release without staging. Should we introduce some staging process > here? I feel reviewing the doc is as important as testing the code, > especially for people who didn't follow the whole development process in > detail. I'm happy how it is, because the site can easily be redeployed. It's not like release artifacts that once distributed over the internet are basically impossible to recall. I'm unsure too as to what has actually changed for the 3.0 site from before the release to now after the release:perform? > * tiles.apache.org/: OK, but that one is managed with a completely > different lifecycle, so we can basically publish it anytime. Or should > it be synchronized with other releases? I think this should happen afterwards. Once the request, autotag, and framework releases are voted on and accepted then it's time to update the apache-tiles-site. There's a number of things here to update. > Additionally, since some of the web sites have been published during mvn > release:perform, should I publish the rest by hand right now and provide > a consistent web site to our users? I'm not following, what do you mean? ~mck -- "If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it. This you have the power to revoke." Marcus Aurelius | http://github.com/finn-no | http://tech.finn.no | |
signature.asc (205 bytes) |
|
|
|
|
|
|
|
On Tue, 2012-05-08 at 12:50 -0400, Nicolas LE BAS wrote:
> > Is this correct? To me it does. Maybe the list before my days has related discussions? Greg? ~mck -- "For a long time it puzzled me how something so expensive, so leading edge, could be so useless, and then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match." Bill Bryson | http://github.com/finn-no | http://tech.finn.no | |
|
|
In reply to this post by Nicolas LE BAS-2
On Tue, 2012-05-08 at 12:37 -0400, Nicolas LE BAS wrote:
> > That is basically the question I've been asking above: What happens > > behind the scenes when you release a version? And that's what I wanted > > to test :) > > Well, testing shows nothing happenning behind the scenes, clicking the > "release" button only adds a release date to the version (and you may > choose the date). You can even unrelease it afterwards. I believe it also moves it from unreleased to released category in the drop down list for fix version field on an issue's edit screen. ~mck -- "We get a million calls a month saying, 'hey, this product is confusing." Bill Gates | http://github.com/finn-no | http://tech.finn.no | |
|
|
|
|
|
In reply to this post by Nicolas LE BAS-2
On Tue, 2012-05-08 at 12:50 -0400, Nicolas LE BAS wrote:
> We'd like the following situation during the voting process: > - artifacts available in the staging repository for maven. > - assemblies available at http://people.apache.org/builds/tiles/*. > - JIRA: a release date on the version > - the web site of the released version available at > http://tiles.apache.org/framework, > http://tiles.apache.org/tiles-autotag, > http://tiles.apache.org/tiles-request. > - the main web site http://tiles.apache.org/ is not updated, even if it > may point to the new doc. > > After the vote: > - artifacts published (including in in maven central). > - assemblies available at http://www.apache.org/dist/tiles/*. > - issues closed in JIRA > - the main web site http://tiles.apache.org/ starts promoting the > released version. > > Is this correct? It's only "issues closed in JIRA" which isn't described in http://tiles.apache.org/framework/dev/release.html ? ~mck -- "As you go the way of life, you will see a great chasm. Jump. It is not as wide as you think." Native American Initiation Rite | http://github.com/finn-no | http://tech.finn.no | |
|
|
|
|
|
|
In reply to this post by Nicolas LE BAS-2
On Sat, 2012-05-12 at 13:32 -0400, Nicolas LE BAS wrote:
> > It's only "issues closed in JIRA" which isn't described in > > http://tiles.apache.org/framework/dev/release.html ? > > No. As I said in my first message, the web page assumes that mvn > release:perform deploys only the artifacts into the staging repository. > Both the Web sites and the assemblies (downloads from the web site) are > said to be deployed by hand. Reading the documentation i interpret it that mvn release:perform is supposed to deploy the web site. The talk about deploying the website under the "Post vote operations" i read as only referring to deploying the 'site' project and that it was given that the framework, request, and autotag projects were in fact deployed during the release... > * deploying the web sites. According to the release process, this > should happen later, after the release has been approved by vote. I missed this point in your original post (although it got addressed in a latter reference in that same post). I can see the ambiguity in the release documentation though. "Perform the Release" could explicitly say that along with deploying artifacts to the staging repository it will also update the project web site. And the "Call for a vote" could mention that the project site can be moderated where it is, although as Greg says none of the sites are ever actually being voted on. ~mck -- "Perl: The only language that looks the same before and after RSA encryption." Keith Bostic | http://github.com/finn-no | http://tech.finn.no | |
Loading...
| Powered by Nabble | Edit this page |