On Wed, Aug 14, 2013 at 4:24 PM, Marcus (OOo) <marcus.m...@wtnet.de> 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. However, back to the original topic of this thread: We should look to see when the bugs we're fixing in 4.0.1 were added to the code. Not to blame or make anyone feel bad. But to understand. If these were late bugs then an earlier beta would not have found them. -Rob > >> The wiki page for the dev builds were too complicated and sounded to >> much beta to make the users confident in using them (when they managed >> to get on that page!). > > > Marcus > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
