Re: [collections] beta release - howto
Thanks for bringing me into context, Phil. Of course, I agree with all your points. Jochen On Mon, Apr 29, 2013 at 4:51 PM, Phil Steitz phil.ste...@gmail.com wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Phil Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? Bye, Thomas. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/release.html#what Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then what policy wrt to user support? E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 4/30/13 7:51 AM, Gilles wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. Projects are free to decide how to name and classify releases as they see fit. Some projects [1] classify releases as alpha, beta, stable *after* they have been tested by users. The *requirement* is just that anything released and publicised via web site links, announcements, etc. must go through the release process, as defined by the PMC, meeting the minimum ASF requirements [2]. If such releases are done, then what policy wrt to user support? Here again, this is up to the PMC to decide. All that the ASF mandates is that releases are properly vetted by the owning PMC and meet the minimum requirements. E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. Should not be, really. We are making good progress - thanks to you and others - getting to an automated release process. Cutting alpha/beta releases including votes and compliance checks should not be that hard and pushing the alpha/beta artifacts to snapshot (and / or release) maven repos will make it easy for users to test. Phil [1] http://tomcat.apache.org/whichversion.html [2] http://www.apache.org/dev/release.html#what-must-every-release-contain Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#whathttp://www.apache.org/dev/release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then what policy wrt to user support? E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. It's not either/or here. Snapshots are not prohibited. It's possible for interested parties to use snapshots. Gilles --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#whathttp://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then what policy wrt to user support? E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. It's not either/or here. Snapshots are not prohibited. It's possible for interested parties to use snapshots. Gilles --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
Le 30/04/2013 17:59, Honton, Charles a écrit : Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? I don't know, but nightly builds are already pushed to the snapshot repository: https://repository.apache.org/content/groups/snapshots/org/apache/commons/ Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then what policy wrt to user support? E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. It's not either/or here. Snapshots are not prohibited. It's possible for interested parties to use snapshots. Gilles --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. This seems a sensible policy to me. Alpha / beta releases are pushed to the mirrors as tars / zips and then *removed* once the stable release is cut (you can see there is no trace of the lang 3 betas in the archives or linked on the site). Since you can't remove anything from the mirrored maven repos, we chose not to push the beta jars there. Seems to have worked OK for the [lang] 3 betas. I would say do the same thing for [collections] 4 and others that are making major API changes and want to get user feedback before pouring cement. Phil Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then what policy wrt to user support? E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. It's not either/or here. Snapshots are not prohibited. It's possible for interested parties to use snapshots. Gilles --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 30 April 2013 17:52, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. I'm not sure it's possible to upload a non-SNAPSHOT bundle to the snapshots repo via Nexus, but I could be wrong. This seems a sensible policy to me. Alpha / beta releases are pushed to the mirrors as tars / zips and then *removed* once the stable release is cut (you can see there is no trace of the lang 3 betas in the archives or linked on the site). I thought the ASF archive site was supposed to contain everything that had ever been released? And indeed the beta tarballs are still there. However as you say, they are not referenced elsewhere, so that will do no harm. Since you can't remove anything from the mirrored maven repos, we chose not to push the beta jars there. That is always an option, though it may make it somewhat harder to reference the dependency in Maven. Seems to have worked OK for the [lang] 3 betas. I would say do the same thing for [collections] 4 and others that are making major API changes and want to get user feedback before pouring cement. Provided that the API does not change incompatibly, then there is no issue with publishing Alpha and Beta releases to Maven Central. Likewise, provided users take heed of any warnings about possible API changes in Alpha releases then there is no problem. They will either not release jars that depend on the Alpha code, or if they do, they must propagate the warning and update their jar as soon as a new release comes out. Seems to me what we are guarding against here is users who ignore warnings that the API might change. If we can do that easily, then fine, let's try and do it. But there's only so far that we should go in order to guard against users who ignore such warnings. Phil Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done,
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 4/30/13 10:19 AM, sebb wrote: On 30 April 2013 17:52, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. I'm not sure it's possible to upload a non-SNAPSHOT bundle to the snapshots repo via Nexus, but I could be wrong. It was labelled 3.0-SNAPSHOT, IIRC. This seems a sensible policy to me. Alpha / beta releases are pushed to the mirrors as tars / zips and then *removed* once the stable release is cut (you can see there is no trace of the lang 3 betas in the archives or linked on the site). I thought the ASF archive site was supposed to contain everything that had ever been released? And indeed the beta tarballs are still there. However as you say, they are not referenced elsewhere, so that will do no harm. Since you can't remove anything from the mirrored maven repos, we chose not to push the beta jars there. That is always an option, though it may make it somewhat harder to reference the dependency in Maven. Seems to have worked OK for the [lang] 3 betas. I would say do the same thing for [collections] 4 and others that are making major API changes and want to get user feedback before pouring cement. Provided that the API does not change incompatibly, then there is no issue with publishing Alpha and Beta releases to Maven Central. Likewise, provided users take heed of any warnings about possible API changes in Alpha releases then there is no problem. They will either not release jars that depend on the Alpha code, or if they do, they must propagate the warning and update their jar as soon as a new release comes out. Seems to me what we are guarding against here is users who ignore warnings that the API might change. If we can do that easily, then fine, let's try and do it. But there's only so far that we should go in order to guard against users who ignore such warnings. Phil Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug reports and patches, they can be directed to snapshots for testing. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. If such releases are done, then
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 30 April 2013 18:25, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 10:19 AM, sebb wrote: On 30 April 2013 17:52, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. I'm not sure it's possible to upload a non-SNAPSHOT bundle to the snapshots repo via Nexus, but I could be wrong. It was labelled 3.0-SNAPSHOT, IIRC. But surely that's not an Alpha or a Beta release? This seems a sensible policy to me. Alpha / beta releases are pushed to the mirrors as tars / zips and then *removed* once the stable release is cut (you can see there is no trace of the lang 3 betas in the archives or linked on the site). I thought the ASF archive site was supposed to contain everything that had ever been released? And indeed the beta tarballs are still there. However as you say, they are not referenced elsewhere, so that will do no harm. Since you can't remove anything from the mirrored maven repos, we chose not to push the beta jars there. That is always an option, though it may make it somewhat harder to reference the dependency in Maven. Seems to have worked OK for the [lang] 3 betas. I would say do the same thing for [collections] 4 and others that are making major API changes and want to get user feedback before pouring cement. Provided that the API does not change incompatibly, then there is no issue with publishing Alpha and Beta releases to Maven Central. Likewise, provided users take heed of any warnings about possible API changes in Alpha releases then there is no problem. They will either not release jars that depend on the Alpha code, or if they do, they must propagate the warning and update their jar as soon as a new release comes out. Seems to me what we are guarding against here is users who ignore warnings that the API might change. If we can do that easily, then fine, let's try and do it. But there's only so far that we should go in order to guard against users who ignore such warnings. Phil Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. Not entirely; if a user is participating in development via bug
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
On 4/30/13 10:29 AM, sebb wrote: On 30 April 2013 18:25, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 10:19 AM, sebb wrote: On 30 April 2013 17:52, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. I'm not sure it's possible to upload a non-SNAPSHOT bundle to the snapshots repo via Nexus, but I could be wrong. It was labelled 3.0-SNAPSHOT, IIRC. But surely that's not an Alpha or a Beta release? The actual release is what is on the ASF mirrors. Pointing people at the SNAPSHOT for maven-assisted testing was a workaround. Seems a reasonable workaround to me. The problem with the public maven repos is you can never delete anything from them and we don't want the betas to be long-lived in the wild. Phil This seems a sensible policy to me. Alpha / beta releases are pushed to the mirrors as tars / zips and then *removed* once the stable release is cut (you can see there is no trace of the lang 3 betas in the archives or linked on the site). I thought the ASF archive site was supposed to contain everything that had ever been released? And indeed the beta tarballs are still there. However as you say, they are not referenced elsewhere, so that will do no harm. Since you can't remove anything from the mirrored maven repos, we chose not to push the beta jars there. That is always an option, though it may make it somewhat harder to reference the dependency in Maven. Seems to have worked OK for the [lang] 3 betas. I would say do the same thing for [collections] 4 and others that are making major API changes and want to get user feedback before pouring cement. Provided that the API does not change incompatibly, then there is no issue with publishing Alpha and Beta releases to Maven Central. Likewise, provided users take heed of any warnings about possible API changes in Alpha releases then there is no problem. They will either not release jars that depend on the Alpha code, or if they do, they must propagate the warning and update their jar as soon as a new release comes out. Seems to me what we are guarding against here is users who ignore warnings that the API might change. If we can do that easily, then fine, let's try and do it. But there's only so far that we should go in order to guard against users who ignore such warnings. Phil Note that the entries in a snapshot repo can be deleted/replaced at any time. (*) Before Nexus, accidents happened and some snapshots were incorrectly uploaded. This can cause version hell (cf. jar hell). Chas On 4/30/13 8:28 AM, sebb seb...@gmail.com wrote: On 30 April 2013 15:51, Gilles gil...@harfang.homelinux.org wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/**release.html#what http://www.apache.org/dev/ release.html#what Thanks for this clarification. Unfortunately, the
Re: [collections] beta release - howto
Am 30.04.2013 17:17, schrieb Phil Steitz: On 4/30/13 7:51 AM, Gilles wrote: On Tue, 30 Apr 2013 07:36:10 -0700, Phil Steitz wrote: On 4/29/13 11:49 PM, Thomas Vandahl wrote: On 30.04.2013 00:01, Gilles wrote: If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. I completely agree with you. Looking at the Commons components, all users are also developers one way or another, as the components are merley libraries, not applications. From what I understand of the Maven idea, snapshots are *the* way binaries can be distributed for testing - including separate storage in a separate repository. The whole repository infrastructure was made for this. The snapshot status carries the clear message that this binary is not for production use and can change its API anytime. So why not use this? The problem with publicising snapshots is that it makes it look like they are actual releases. This has been discussed a lot over the years, and we have settled on the policy [1] that anything that we encourage anyone beyond the developers actively following the dev list (developers per the definition above), *must* be treated as a release. [1] http://www.apache.org/dev/release.html#what Thanks for this clarification. Unfortunately, the description of release does not provide a solution to the problem posed. Essentially, it only forbids to ask for user feedback on unreleased code. The only way out is to release: If this policy seems inconvenient, then release more often. But release what? alpha, beta? Those are not defined there. Projects are free to decide how to name and classify releases as they see fit. Some projects [1] classify releases as alpha, beta, stable *after* they have been tested by users. The *requirement* is just that anything released and publicised via web site links, announcements, etc. must go through the release process, as defined by the PMC, meeting the minimum ASF requirements [2]. If such releases are done, then what policy wrt to user support? Here again, this is up to the PMC to decide. All that the ASF mandates is that releases are properly vetted by the owning PMC and meet the minimum requirements. E.g. do we _have_ to (quickly) create bug fix releases for such releases (known to be more fragile)? This looks much more complicated than just asking interested parties to manually download a nightly build (with all the caveats and warnings), temporarily add it to their classpath and look for unexpected problems. Should not be, really. We are making good progress - thanks to you and others - getting to an automated release process. Cutting alpha/beta releases including votes and compliance checks should not be that hard and pushing the alpha/beta artifacts to snapshot (and / or release) maven repos will make it easy for users to test. +1 to going to the full release process. But it is not yet clear to me for which kind of releases/version schemes changes on the public API are allowed. I mean, this is the purpose of the whole exercise: to gain feedback which may cause API changes before the final release is made. Oliver Phil [1] http://tomcat.apache.org/whichversion.html [2] http://www.apache.org/dev/release.html#what-must-every-release-contain Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [PMC] Alpha Binaries Release Policy (was Re: [collections] beta release - howto)
Phil Steitz wrote: On 4/30/13 10:29 AM, sebb wrote: On 30 April 2013 18:25, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 10:19 AM, sebb wrote: On 30 April 2013 17:52, Phil Steitz phil.ste...@gmail.com wrote: On 4/30/13 9:28 AM, sebb wrote: On 30 April 2013 16:59, Honton, Charles charles_hon...@intuit.com wrote: Is there any policy concern with publishing the binaries of alpha releases, after vote, to a Apache snapshot repository which is not replicated to Maven Central? Not sure that question makes sense as posed. If a build is voted on, it is a release, and is not a snapshot. AFAIK snapshots are never voted on so cannot become releases. Snapshots can be uploaded to a snaphot repo without needing a vote. Snapshots can (*) only be uploaded to snapshot repos; they cannot be uploaded to release repos. AFAIK the reverse is also true, releases are never uploaded to snapshot repos. IIRC, what we did with the [lang] 3.0 betas was not push the beta releases to maven central, but we *did* update the snapshot repos. I'm not sure it's possible to upload a non-SNAPSHOT bundle to the snapshots repo via Nexus, but I could be wrong. It was labelled 3.0-SNAPSHOT, IIRC. But surely that's not an Alpha or a Beta release? The actual release is what is on the ASF mirrors. Pointing people at the SNAPSHOT for maven-assisted testing was a workaround. Seems a reasonable workaround to me. The problem with the public maven repos is you can never delete anything from them and we don't want the betas to be long-lived in the wild. +1 - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). I think it would be useful to ensure that all generics warnings are fixed - including test code - before any release. That's one way of ensuring that the API is reasonable - users should not have to ignore generics warnings. Also the non-private mutable fields should have getters. Ideally no setters, as they make thorough testing much harder, though that's not always possible. I'm willing to convert the fields to private if that would suit you (COLLECTIONS-455) I may also have time to fix some generics warnings in the test code. Thomas On Sun, Apr 28, 2013 at 8:56 PM, sebb seb...@gmail.com wrote: On 28 April 2013 18:27, Henri Yandell flame...@gmail.com wrote: Is less attention paid to the API for an alpha/beta? If the idea is to be able to change the API (possibly breaking compatibility) then I don't think a Beta release is appropriate. That would be for an Alpha release - and we would have to make very clear that a subquent release might break compatibility. I think that's about the only situation where Commons might release a binary-incompatible jar without changing Maven coords or package name. I think a Beta release is more suitable for indicating that there may be quite a few bugs in the code, so users should only upgrade if they are prepared for this. In any case any release needs to go through the usual release vote process. Hen On Sat, Apr 27, 2013 at 10:16 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: There is nothing special. Even with alpha, or beta as part of the version number, it is technically an ASF release, and therefore subject to the full blown process and rules. On Thu, Apr 25, 2013 at 8:57 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). On Mon, Apr 29, 2013 at 10:42 AM, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). Thomas On Sun, Apr 28, 2013 at 8:56 PM, sebb seb...@gmail.com wrote: On 28 April 2013 18:27, Henri Yandell flame...@gmail.com wrote: Is less attention paid to the API for an alpha/beta? If the idea is to be able to change the API (possibly breaking compatibility) then I don't think a Beta release is appropriate. That would be for an Alpha release - and we would have to make very clear that a subquent release might break compatibility. I think that's about the only situation where Commons might release a binary-incompatible jar without changing Maven coords or package name. I think a Beta release is more suitable for indicating that there may be quite a few bugs in the code, so users should only upgrade if they are prepared for this. In any case any release needs to go through the usual release vote process. Hen On Sat, Apr 27, 2013 at 10:16 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: There is nothing special. Even with alpha, or beta as part of the version number, it is technically an ASF release, and therefore subject to the full blown process and rules. On Thu, Apr 25, 2013 at 8:57 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. Jochen
Re: [collections] beta release - howto
On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Phil Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 29 April 2013 15:51, Phil Steitz phil.ste...@gmail.com wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Also snapshots must not be advertised to the general public; they are for developer use only. e.g. I think it's OK to mention them in a JIRA so interested parties can test if a bug has been fixed, but not on the user list nor on download pages. Phil Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 04/29/2013 11:02 AM, sebb wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). I think it would be useful to ensure that all generics warnings are fixed - including test code - before any release. That's one way of ensuring that the API is reasonable - users should not have to ignore generics warnings. Afaik there are not many generics warnings left in the src folder, but we should fix them of course. Also the non-private mutable fields should have getters. Ideally no setters, as they make thorough testing much harder, though that's not always possible. I'm willing to convert the fields to private if that would suit you (COLLECTIONS-455) I have looked a bit at the list, and I am not sure if all of them need to be converted, e.g. in SynchronizedCollection the fields in question are already final, but please go ahead. I may also have time to fix some generics warnings in the test code. That would be great. btw. it would also be of great help if somebody could take a look at the site docs. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 04/29/2013 04:51 PM, Phil Steitz wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. thanks Phil, I couldn't have summarized it better. I think we should make the release process easier, and aim for more alpha/beta releases, I am sure the community and the involved developers will benefit from it, imho. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote: On 29 April 2013 15:51, Phil Steitz phil.ste...@gmail.com wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Also snapshots must not be advertised to the general public; they are for developer use only. ??? Developers build from source; they don't need the snapshots. e.g. I think it's OK to mention them in a JIRA so interested parties can test if a bug has been fixed, but not on the user list nor on download pages. The main contribution which users can offer is to test snapshots and provide feedback on regressions in their applications. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 29 April 2013 21:49, Gilles gil...@harfang.homelinux.org wrote: On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote: On 29 April 2013 15:51, Phil Steitz phil.ste...@gmail.com wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Also snapshots must not be advertised to the general public; they are for developer use only. ??? Developers build from source; they don't need the snapshots. Not necessarily; they may be developing an app that depends on Commons. Why should they have to additionally set up their system to build a Commons component? Their system might not use Maven. Regardless, snapshots are not for the general public. e.g. I think it's OK to mention them in a JIRA so interested parties can test if a bug has been fixed, but not on the user list nor on download pages. The main contribution which users can offer is to test snapshots and provide feedback on regressions in their applications. Regards, Gilles --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On 29 April 2013 19:36, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/29/2013 11:02 AM, sebb wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). I think it would be useful to ensure that all generics warnings are fixed - including test code - before any release. That's one way of ensuring that the API is reasonable - users should not have to ignore generics warnings. Afaik there are not many generics warnings left in the src folder, but we should fix them of course. Also the non-private mutable fields should have getters. Ideally no setters, as they make thorough testing much harder, though that's not always possible. I'm willing to convert the fields to private if that would suit you (COLLECTIONS-455) I have looked a bit at the list, and I am not sure if all of them need to be converted, e.g. in SynchronizedCollection the fields in question are already final, but please go ahead. I may also have time to fix some generics warnings in the test code. That would be great. btw. it would also be of great help if somebody could take a look at the site docs. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
Sorry, hit wrong button - not yet used to the new GMail. On 29 April 2013 19:36, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 04/29/2013 11:02 AM, sebb wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. I could imagine doing a first alpha till next week, and postpone some changes to an alpha2 release, as I will need a bit more time to work on the Trie interface and maybe add a fluent API for iterators (see COLLECTIONS-442). I think it would be useful to ensure that all generics warnings are fixed - including test code - before any release. That's one way of ensuring that the API is reasonable - users should not have to ignore generics warnings. Afaik there are not many generics warnings left in the src folder, but we should fix them of course. No, there aren't many source warnings. But it's the process of fixing the test code warnings that will show if there are issues using the code. Also the non-private mutable fields should have getters. Ideally no setters, as they make thorough testing much harder, though that's not always possible. I'm willing to convert the fields to private if that would suit you (COLLECTIONS-455) I have looked a bit at the list, and I am not sure if all of them need to be converted, e.g. in SynchronizedCollection the fields in question are already final, but please go ahead. SynchronizedCollection has two protected final fields: collection lock collection itself is final, but the entries are not. lock is final, but it seems odd to publish a lock outside a class but only allow sub-classes to use it. I may also have time to fix some generics warnings in the test code. That would be great. btw. it would also be of great help if somebody could take a look at the site docs. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
On Mon, 29 Apr 2013 22:47:15 +0100, sebb wrote: On 29 April 2013 21:49, Gilles gil...@harfang.homelinux.org wrote: On Mon, 29 Apr 2013 16:56:02 +0100, sebb wrote: On 29 April 2013 15:51, Phil Steitz phil.ste...@gmail.com wrote: On 4/29/13 5:39 AM, Jochen Wiedmann wrote: On Mon, Apr 29, 2013 at 11:02 AM, sebb seb...@gmail.com wrote: On 29 April 2013 09:42, Thomas Neidhart thomas.neidh...@gmail.com wrote: Well, I certainly *want* to change the API if something is broken, so I guess an alpha release would be safer. Please keep upwards compatibility to any previous releases in mind. Commons' reputation relies heavily on that. I agree with this in general, but there are two special things going on here: 0) What Thomas is looking to alpha is [collections] 4, which is a major release that brings in generics, so will not be backward compatible with previous releases. 1) Given the amount of API change, we want feedback on the API if we can get it during an alpha period IIRC, we did this for [lang] 3.0, but called in beta. I can't remember how exactly we managed the messaging and publication of artifacts, but it appears that the beta has now pretty much vanished. Maybe Hen can describe how we handled that. I think that as long a) we make it clear in release notes and on the web page that what we are releasing in the alpha may have incompatible API fixes added in the final 4.0 release and b) we get the final out fairly soon after (maybe a month or two), I don't see a problem with this. Looking back on [math] 3 and forward to [math] 4, I think we would benefit there as well from the ability to cut alpha releases so we can fix API bugs during an alpha review period. It would be great if we could settle on a way to do this without causing too much pain for users and Commons developers. The keys are probably strong warnings on the alphas, relatively short alpha eval periods and maybe foregoing pushing alphas to the public maven repos. The only alternative to this approach (other than just living with whatever API mistakes we make until the next major release) is to publicize a snapshot, which I think is a worse option because if we want users outside of the immediate development community to use something, we should follow the normal steps to cut an official release. Also snapshots must not be advertised to the general public; they are for developer use only. ??? Developers build from source; they don't need the snapshots. Not necessarily; they may be developing an app that depends on Commons. Why should they have to additionally set up their system to build a Commons component? Their system might not use Maven. If someone doesn't develop a Commons component, he is not in the developer category for that component. If his app _uses_ a Commons component, he is a user of that component. This kind of users should indeed be encouraged to test snapshots, and report problems _before_ an official release is made. Regardless, snapshots are not for the general public. What is the general public here? An application's user (someone who just _runs_ an application that uses a Commons component) does not belong in the user category as intended here. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] beta release - howto
Is less attention paid to the API for an alpha/beta? Hen On Sat, Apr 27, 2013 at 10:16 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: There is nothing special. Even with alpha, or beta as part of the version number, it is technically an ASF release, and therefore subject to the full blown process and rules. On Thu, Apr 25, 2013 at 8:57 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
On 28 April 2013 18:27, Henri Yandell flame...@gmail.com wrote: Is less attention paid to the API for an alpha/beta? If the idea is to be able to change the API (possibly breaking compatibility) then I don't think a Beta release is appropriate. That would be for an Alpha release - and we would have to make very clear that a subquent release might break compatibility. I think that's about the only situation where Commons might release a binary-incompatible jar without changing Maven coords or package name. I think a Beta release is more suitable for indicating that there may be quite a few bugs in the code, so users should only upgrade if they are prepared for this. In any case any release needs to go through the usual release vote process. Hen On Sat, Apr 27, 2013 at 10:16 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: There is nothing special. Even with alpha, or beta as part of the version number, it is technically an ASF release, and therefore subject to the full blown process and rules. On Thu, Apr 25, 2013 at 8:57 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
There is nothing special. Even with alpha, or beta as part of the version number, it is technically an ASF release, and therefore subject to the full blown process and rules. On Thu, Apr 25, 2013 at 8:57 AM, Thomas Neidhart thomas.neidh...@gmail.comwrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero
Re: [collections] beta release - howto
I think we can make it be the same as releasing a full release. Gary On Apr 25, 2013, at 2:57, Thomas Neidhart thomas.neidh...@gmail.com wrote: Hi, I have seen that the log4j team prepared a new beta for v2. As collections 4 is very close to be ready, I'd like to know more about the process of beta releases, as I am planning to do the same for collections 4. Can somebody enlighten me a bit? Thanks, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
