On Wed, Aug 14, 2013 at 3:35 PM, sebb <[email protected]> wrote: > On 14 August 2013 23:10, Rob Weir <[email protected]> wrote: > > On Wed, Aug 14, 2013 at 4:24 PM, Marcus (OOo) <[email protected]> > wrote: > >> Am 08/14/2013 10:05 PM, schrieb Hagar Delest: > >> > >>> Le 14/08/2013 21:39, Rob Weir a écrit : > >>>> > >>>> Maybe we need to call an earlier build the "RC" so it will get more > >>>> attention? We had a complete test build that we were testing for > >>>> over a month. But maybe it is ignored unless we call it an "RC"? In > >>>> other words, there were many opportunities for users to help try 4.0 > >>>> before it was released, but maybe there opportunities were not well > >>>> known. > >>> > >>> > >>> I think that it was too difficult to get to the dev versions and it was > >>> too much complicated. There was no clear link to download a dev version > >>> (I had to rely on the url in the messages from the dev list). > >> > >> > >> This was intended. > >> > >> We hadn't published the dev builds via Apache or SF mirrors but only on > 2 > >> people accounts. Apache policy says it's not allowed to publish them > for a > >> wider audience to save the servers from a high traffic load. It's the > job of > >> the mirrors to handle this. > >> > >> > >>> What I see (from a standard user point of view) for a RC: > >>> - When a dev version is almost done, rename it RC and make it known > >>> (blog and we would relay the announcement in the forums of course) > >>> - Have a link visible under the main download button of the download > >> > >> > >> Both can be done, depending where the install files are located. > >> > >> > >>> page (perhaps a similar button as a dedicated entry) > >>> - Make that RC installable in parallel with a stable version > >>> - No file association allowed for that RC by design > >> > >> > >> IMHO the last both points doesn't apply to a RC [1] as it wouldn't be a > RC > >> anymore. One of the RC attributes is to change it into the final release > >> with, e.g., just a file name change. But this has to be done without any > >> code changes. Otherwise you have to change code parts, build again, test > >> again, ... ;-) > >> > >> But a Beta release could go this separated way. > >> > > > > Right. A release is a release is a release. The basic requirements > > for every release still apply: > > > > 1) 3 PMC +1 votes > > 2) Must include source files > > 3) Digital signatures, hash files, etc. > > > > But we can have a "beta release", that follows these rules, and it > > would be acceptable. We can then host on the mirrors, publicize, etc. > > There would likely be some restrictions on how many extra downloads > are permitted. > For example, the ASF mirrors probably could not cope with a set of > betas of all the languages for all the OSes in addition to the current > GA release. >
Looking again at this thread, and knowing the amount of time and resources it takes to actually mount an approved release, I wonder if some of the issues we had with the 4.0 release could have been addressed by a longer RC vote timeframe -- like 2 weeks or so. The vote this time was relatively short as I recall on both the original RC and RC2. We have over 400 people on this list. I would hope given a longer test period, we might receive better testing and feedback if we took a bit longer for approval. I realize this is not the same as a beta -- we would still be using "development snapshots", but the RC could be provided in all languages we intend to use, etc. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ------------------------------------------------------------------------------------------------- MzK "When in doubt, cop an attitude." -- Cat laws
