Re: ranges and cascading releases was: [VOTE]: release maven-changes-plugin 2.6
Technically I'd get away with updating 2-3 artifacts, but I'd end up writing a cookbook on how to add a crapload of dependencies to the plugins in question and answering on the mailing list and irc, and in the end we'd have a ton of poms lying around with 3 overridden dependencies in 4-5 plugins. So as as service to our end users I think the fair thing is to release new versions. Now given that we manage to maintain an average release schedule of 4-8 weeks, I would probably just ignore releasing the plugin, but currently I think our release schedules are driven by itches like mine. So I suppose we *could* solve this by just assigning regular releases to committers. Personally I don't /mind/ taking responsibility for releasing 2-3 plugins every 6-8 weeks if I knew someone else did the others. I think version ranges for plugins are fairly dangerous because you'll be removing the determinism in the build. Even though you lock down plugin versions, you risk getting a new version of maven-shared-foobar any day. I just need introduce *1* platform specific bug in maven-shared-foobar to paralyze the entire community of windows users. I've seen this happen in other projects that (for instance) have *no* committers working on windows (yes, it's becoming fairly commonplace). Kristian Den 21.06.2011 02:38, skrev Brett Porter: Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied. - Brett On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian
Re: ranges and cascading releases was: [VOTE]: release maven-changes-plugin 2.6
I'm with Kristian, as if he needs any help here. We aren't anywhere near where we'd have to be to feel confident that a release of some component was guaranteed regression-free in all obscure cases. One small thought: if people would mark their votes 'binding' or 'nonbinding', it would reduce the effort of collating them. The easier the process is, the more releases we can make. I'm always happy to rm. On Tue, Jun 21, 2011 at 2:57 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Technically I'd get away with updating 2-3 artifacts, but I'd end up writing a cookbook on how to add a crapload of dependencies to the plugins in question and answering on the mailing list and irc, and in the end we'd have a ton of poms lying around with 3 overridden dependencies in 4-5 plugins. So as as service to our end users I think the fair thing is to release new versions. Now given that we manage to maintain an average release schedule of 4-8 weeks, I would probably just ignore releasing the plugin, but currently I think our release schedules are driven by itches like mine. So I suppose we *could* solve this by just assigning regular releases to committers. Personally I don't /mind/ taking responsibility for releasing 2-3 plugins every 6-8 weeks if I knew someone else did the others. I think version ranges for plugins are fairly dangerous because you'll be removing the determinism in the build. Even though you lock down plugin versions, you risk getting a new version of maven-shared-foobar any day. I just need introduce *1* platform specific bug in maven-shared-foobar to paralyze the entire community of windows users. I've seen this happen in other projects that (for instance) have *no* committers working on windows (yes, it's becoming fairly commonplace). Kristian Den 21.06.2011 02:38, skrev Brett Porter: Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied. - Brett On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand
Re: [VOTE]: release maven-changes-plugin 2.6
Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. What do you base your vote on exactly? Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Gav... -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.htm l Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools. The source package must be cryptographically signed by the Release Manager with a detached signature; and that package together with its signature must be tested prior to voting +1 for release. Folks who vote +1 for release may offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release. * Note that the PMC is responsible for all artifacts in their distribution directory, which is a subdirectory of www.apache.org/dist/ ; and all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. It is also necessary for the PMC to ensure that the source package is sufficient to build any binary artifacts associated with the release. * Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. More information can be found in the foundation website and in the release licensing FAQ. Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. There are a lot of companies out there who will make their employees jump through hoops if they want to built with a patched version of build tools that has not come from the build tool's distributor. Thus to help those people often times it is necessary to roll a release with the few lines of code as the issue _IS_BLOCKING_TO_THEM_ might be non-blocking to everyone else. We want people to play nice by the community. So please remember that often times these things are done to support the community. What people do not like is when the efforts of volunteers are criticized for not being enough work... we are not paid for doing this work, we do this in our spare time. Sometimes we get abuse from our spouses for working on this in our spare time... if all we have time to to is roll out a release with one minor (to you) fix, and no fixes for the issue you have... well why don't you STEP UP and provide a patch for that issue, and you know what, a committer might just pick up that patch and apply the patch and roll a release with that one minor (to them) fix included. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Actually, don't
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. 4: An Apache principle is to encourage people to scratch their itches. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. Is there some particular reason why you've chosen to blow a whistle about this particular question? --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools. The source package must be cryptographically signed by the Release Manager with a detached signature; and that package together with its signature must be tested prior to voting +1 for release. Folks who vote +1 for release may offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release. * Note that the PMC is responsible for all artifacts in their distribution directory, which is a subdirectory of www.apache.org/dist/ ; and all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. It is also necessary for the PMC to ensure that the source package is sufficient to build any binary artifacts associated with the release. * Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain appropriate LICENSE and NOTICE files. More information can be found in the foundation website and in the release licensing FAQ. Rolling a new release for a few lines of code that fixes a couple of bugs
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1 votes from the PMC for that Apache project. Each voting PMC member is required to ensure that releases meet the following: * Every ASF release
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, Since I seem to have misread your tone, I apologize. --benson On Mon, Jun 20, 2011 at 7:53 AM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin, Don't take it personal. I have expressed my opinion like you have expressed yours, and we are both entitled to do so. But you have to realize that your comments were taken with offence by some developers. I have been with maven for several years now, I know we have taken criticism for not releasing often enough, for releasing incomplete stuff, for releasing broken stuff, for releasing undocumented stuff; but this is the first time I remember that we take some heat for releasing too often. I guess I simply still have to learn how to deal with it! :) -Lukas Gavin McDonald wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. What do you base your vote on exactly? Rolling a new release for a few lines of code that fixes a couple of bugs and does not introduce any new functionality is overkill IMHO. But I will stay out of such votes/threads/opinions in the future , do what I joined this list for, then leave when I'm done. Gav... -Lukas Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQue ry= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.htm l Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, 20 June 2011 9:00 PM To: Maven Developers List Cc: ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin, When you sent your message containing the words, ignore me, I was planning to take you at your word. But since you seem to have continued to continue your campaign of sneer here I guess I'll respond. 1: As it turned out, the vote that started all this concerned 10 issues. I was misled by a JIRA feature. Sure, understandable, I too followed the link you gave as part of the vote. 2: The amount of developer work that goes in is not proportional to the number of JIRAs that come out. I'm not sure I mentioned anything about this. ... 3 issues seems like doing a days work ... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88624.html 3: The amount of user value that comes out is not proportional to the number of JIRAs that go in. I'm not sure I mentioned anything about this. ... Don’t release for the sake of releasing... quoted from http://www.mail-archive.com/dev@maven.apache.org/msg88586.html -Lukas 4: An Apache principle is to encourage people to scratch their itches. After 6 years at Apache I get that. This doesn't work if the change you desperately need gets trapped for months waiting for a release. Or, worse, if you get 'held hostage' by demands to fix additional problems that you don't have the expertise to tackle a the price of a release of what you need to fix. I don’t get how this is relevant to my voting on the specifics of a few lines of changed code. I was basing this on the link you gave to the 3 Jira Issues. We now know it was 10 issues. All in all, it is very handy that Maven has an automated release process that takes the RM 5 minutes and some PMC members a few more to validate his or her work. This lowers the activation energy. That’s good, someone else in this thread earlier was making out it’s a really hard process and so therefore why would anyone do it for the sake of it. Glad to be corrected there. Is there some particular reason why you've chosen to blow a whistle about this particular question? This was no vendetta, no campaign of sneer, nothing against yourself, I know what you do it Apache and where, you work hard, do not take this as anything other than querying why would anyone do a release based on 3 issues and a few lines of code. It was just that , no more, no less, I do not get all the hostility that has come from such a query, than one is entitled to do. Please, let s drop this, I have now unsubscribed from the list. Gav... --benson On Mon, Jun 20, 2011 at 6:08 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 20 June 2011 10:48, Gavin McDonaldga...@16degrees.com.au wrote: -Original Message- From: Lukas Theussl [mailto:ltheu...@gmail.com] On Behalf Of Lukas Theussl Sent: Monday, 20 June 2011 7:25 PM To: Maven Developers List Subject: Re: [VOTE]: release maven-changes-plugin 2.6 Gavin McDonald wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Really? And what in your opinion would be the threshold for a release? 5 issues? 16? And if there are no open issues left, do we have to wait for people to find 8 more before we can release it? Depends on the quality and quantity, whether it fixes a security issue, introduces a new must have feature, etc. I would happily vote +1 for a one line security fix. Context is everything. Seriously, I think this posting will easily make it on our list of 10 most pointless contributions of the year. Do not criticise me for making a vote statement. It was not a contribution, it was a statement regarding the vote, which anyone is entitled to do. When to call a vote for a release is solely the decision of the release manager, and the number of issues is simply irrelevant. Of course, but am I not entitled to express my vote and supporting statement, or are all votes expected to be +1 with no comments. You are entitled to express your vote and supporting statement, but the vote is expected to be based on whether the artifacts are releasable or not. So if for example you identify an issue with the built software, that could be a -1 or -0. Note that you cannot veto releases. A -1 can be ignored by the release manager. What do you base your vote on exactly? There are strict criteria for the PMC on which we are supposed to base our vote on. There are legal requirements that mandate that any release from Apache must have at least three +1
Re: [VOTE]: release maven-changes-plugin 2.6
Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
(Other) Mark, I'm not sure I see the connection here? Lukas had made comment that making one release would trigger cascading releases, which I assume is because downstream plugins have fixed version number dependencies. However if those dependencies were [1.0,2.0) then they would use the most recent automatically without having to rerelease everything. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg strub...@yahoo.de wrote: Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Please make a new thread. On Mon, Jun 20, 2011 at 5:51 PM, Mark Derricutt m...@talios.com wrote: (Other) Mark, I'm not sure I see the connection here? Lukas had made comment that making one release would trigger cascading releases, which I assume is because downstream plugins have fixed version number dependencies. However if those dependencies were [1.0,2.0) then they would use the most recent automatically without having to rerelease everything. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Tue, Jun 21, 2011 at 8:39 AM, Mark Struberg strub...@yahoo.de wrote: Mark, maybe this is not so obvious, but Maven internally has ClassLoader isolation between plugins. This is comparable to a servlet container where 1 webapp only can see its own classes. This way it is no problem that there are more versions of a plugin (or any other dependency) being used in the same maven build. LieGrue, strub --- On Mon, 6/20/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: [VOTE]: release maven-changes-plugin 2.6 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 8:27 PM Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: ranges and cascading releases was: [VOTE]: release maven-changes-plugin 2.6
Kristian can describe in more detail what he's working on, but not all changes take 8 artifact changes. In this case I think it's both that it's something that affects multiple things (rather than dependencies), and also a couple of things that have been broken down to one too separate many artifacts (like plexus-compiler, which I think is only ever used in the compiler plugin). Those sorts of exercises should actually help us understand if the right type of modularity has been applied. - Brett On 21/06/2011, at 6:27 AM, Mark Derricutt wrote: Wow - that seems like a hell of a lot of releases having to be made... This post is probably drifting off topic but the thing that strikes me here is that this is the exact reason why maven supports version ranges - so that you don't have to make a plethora of rolling releases just because one change was made downstream. It's no wonder a lot of version range bugs in maven never get fixed if none of the plugins or maven itself actually uses them. Of course this only solves the problem where an upstream release contains non-breaking changes for its downstream users which hopefully, for bug fixes would be more often than not. Locking down versions is good for third party dependencies, but I'm very much of the mind that ranges should be used for sibings, would certainly solve the problem of transitive release blowouts. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Mon, Jun 20, 2011 at 6:13 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Den 19.06.2011 23:08, skrev Gavin McDonald: I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Given a very quick count, the apache maven project contains something like 90 individually deployable and separately votable artifacts. Our users upgrade these components individually according to need. Each component is individually tested and voted for; maven is not a monolithic application and should not be released as one. The downside of this componentization is that sometimes fixing a single issue leads to the redeployment of multiple artifacts, at the moment I'm working on 1 issue that will require the redeployment of 8 different artifacts (6 votes at apache, 2 elsewhere) before it's closed in its full extent. Most likely I'll have votes for 2 of these soon and I'll just let the remaining 4 roll out together with releases planned by others. But in this context I simply refuse to consider if a single release vote is too large or too small. From an agile perspective there's potential to getting a lot more issues fixed with a single year than the kind of project you mention. I have no specific stats but I assume we fix at least a thousand issues every year. Some of our projects have sufficiently good automated test coverage that I suspect we could allow incremental .1 releases to go without a vote entirely. I'm not sure if this is something we're even allowed to consider ;) (Surefire would probably qualify, assuming we did some kind of formalized continious production kind of review) I think ideally we should release every top-level component every 6 weeks or so. But that means we'd have 1-3 votes every day ;) Kristian --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RE: [VOTE]: release maven-changes-plugin 2.6
don't knock somebody who is taking the time and effort to actually run a release. any improvement is an improvement... you could quibble that maybe it should have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to make the release. speaking with my pmc hat on, any improvement merrits a release... the decision as to whether to take that effort is down to the individual committer who steps up. it may be that benson needs the release in another project, so what you see as trivial may be a blocker to somebody else (personally in those cases I usually add a ref to the project needing the fast release, but there is no requirement to have such a ref). lets keep things positive, and benson, keep up the hard work I'll review the release when at a computer where I can test it - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 09:35, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
I'd rather see a release with 3 bug fixes if they code base is idle than see not see a release for weeks/months whilst someone waits for N more issues to be resolved. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald ga...@16degrees.com.auwrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RE: [VOTE]: release maven-changes-plugin 2.6
1: This [VOTE] is cancelled due to a merge snafu in the prep. 2: for Gavin: I spent several days fixing up a very broken feature to render the plugin actually usable with customized JIRA installations. I want to put that work to work in the real world, and I didn't see any other outstanding issues that I felt qualified to tackle straight off. I also invited the dev@ and pmc@ community to comment on the proposal to make a release several days before I started it, and received no doubts. If people would prefer to call it 2.5.1 tell me now, but I think that the amount of code furniture movement, pace the small JIRA count, justifies 2.6. On Sun, Jun 19, 2011 at 5:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: don't knock somebody who is taking the time and effort to actually run a release. any improvement is an improvement... you could quibble that maybe it should have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to make the release. speaking with my pmc hat on, any improvement merrits a release... the decision as to whether to take that effort is down to the individual committer who steps up. it may be that benson needs the release in another project, so what you see as trivial may be a blocker to somebody else (personally in those cases I usually add a ref to the project needing the fast release, but there is no requirement to have such a ref). lets keep things positive, and benson, keep up the hard work I'll review the release when at a computer where I can test it - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 09:35, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Kristian, How are you seeing 10? --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212version=17375 ?? Den 19. juni 2011 kl. 13:40 skrev Benson Margulies bimargul...@gmail.com: Kristian, How are you seeing 10? --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
On 2011-06-19 13:39, Benson Margulies wrote: Kristian, How are you seeing 10? In the release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 In JIRA 4 the default layout changed so that it shows some sort of summary, which I don't understand the need for at all. It shows the 3 most recently updated issues: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 If you want to see *all* issues for that version (who doesn't?) you need to click on the Issues tab on the left. Not very user friendly is you ask me... --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Well, that explains that. 2.6 it is, and new vote coming soon. On Sun, Jun 19, 2011 at 8:02 AM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 13:39, Benson Margulies wrote: Kristian, How are you seeing 10? In the release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 In JIRA 4 the default layout changed so that it shows some sort of summary, which I don't understand the need for at all. It shows the 3 most recently updated issues: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 If you want to see *all* issues for that version (who doesn't?) you need to click on the Issues tab on the left. Not very user friendly is you ask me... --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Kristian Rosenvold [mailto:kristian.rosenv...@gmail.com] Sent: Sunday, 19 June 2011 7:50 PM To: 'Maven Developers List' Subject: RE: [VOTE]: release maven-changes-plugin 2.6 Dont know if we're looking at the same jira; I see 10 issues being resolved. Probably not, I'm looking at the link that Benson gave: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 and combining that with the words: We solved 3 issues: I think you are looking in the wrong place. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Compared to some other projects, not much work at all. Gav... Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQu ery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.ht ml Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Mark Derricutt [mailto:m...@talios.com] Sent: Sunday, 19 June 2011 9:37 PM To: Maven Developers List; ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 I'd rather see a release with 3 bug fixes if they code base is idle than see not see a release for weeks/months whilst someone waits for N more issues to be resolved. I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Gav... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald ga...@16degrees.com.auwrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE]: release maven-changes-plugin 2.6
Hi, We solved 3 issues: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
