On Sat, May 18, 2013 at 06:51:30PM -0700, Ahmad Emneina wrote: > I agree, there need's to be a caveat the nightly builds are convenience > builds, that shouldnt be used for any type of production environment. Only > for testing. > > > On Sat, May 18, 2013 at 4:43 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > > > I like this idea, as long as it is approached carefully. I would prefer > > that the beta releases be of failed RC quality than pre-RC phase. I know > > these should be at their own risk, take backups, etc, but upgrades are > > notorious for schema upgrade failures. Also, helping people update from > > beta 1 to RC2 and all of the possible permutations seems like a nightmare > > if the database schema/ updates aren't rock solid before the first beta is > > cut. > > On May 18, 2013 4:56 PM, "Ahmad Emneina" <aemne...@gmail.com> wrote: > >
Until a while ago (and purely because we ran out of space on Jenkins master) we hosted artifacts of the nightly packages for those who'd be interested in test driving the new features. That can be enabled back if required during the VOTING phase of a release. But I'm getting slightly confused by the +1s in this discussion: 1. For nightly build/bleeding edge/no-upgrade-support packages - +1 (If someone has a public s3 repo, I can turn it into a yum/apt repo for these) 2. For supporatable betas that can be upgraded to RC/GA quality - -1 I don't think our upgrades, release cadence discpilines are there yet for that. This could be useful in the future though. -- Prasanna., ------------------------ Powered by BigRock.com
