I'm gonna jump in with my $0.02 and say that releasing from 'master' is never a good idea. It just so happens to work out for us now, but I'm pretty sure c0sin is a masochist and we should be wary of anything he suggests. (heart you c0s!)
I, for one, have lofty goals of puppet-4 enablement, but that's clearly a feature that doesn't belong on the 1.2.x train. Freezing 'master' for a 1.2.x point release just makes my feature branch more-and-more outdated during the freeze, so let's not do that. And let's not worry about which jiras belong on which branch at potential release time -- it's too error prone. Let's instead come up with a release process that works for us. Full disclosure in case you didn't recognize my email domain -- I work at Canonical, and the steady Ubuntu release cadence (April / October) has worked very well for us. I'm not suggesting we align Bigtop with those dates, but I *am* suggesting we come up with a regular release cycle that works for us. Here's what I have in mind: - clone 'master' to 'stable' right now; this is the branch from which all 1.2.x releases will be born until 1.3. - features that break backwards compat go on 'master' (when they're ready, of course); bug fixes should make their way to 'stable' as appropriate. - educate committers to be sure of the branch they're committing (i'm guilty of this, as i do not pay much attention to the destination of things i commit -- if the patch applies, it gets pushed to master!). aside: half of us use patches attached to JIRAa; the other (better) half use github PRs. let's pick one way and do that! - define a release cadence: quarterly, biannually, annually, whatever makes sense. personally, i like quarterly. newbies to our project get a stable release that's at-worst 3 months old. this of course brings the burden of a release manager; i'm happy to sign up as the 1.2.2 RM. - integration test strategy. i know juju can test stacks; i'm sure itest or some k8s / container strategy can be used as well. let's build on Evans' matrix [1] to gate releases. this needs to be cross-OS and cross-$arch, as I believe this to be one of the major advantages of Bigtop -- it just works no matter the underlying infra. I know this stuff is like software engineering 101, but I think it's important to keep our band-of-crazies on the same page. If for no other reason, let's just agree on something for my sake. Thoughts? [1] https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop-trunk-deployments/ Thanks! -Kevin On Tue, Jun 27, 2017 at 1:00 PM, Konstantin Boudnik <[email protected]> wrote: > Releasing from master is ok but would actually create more work than > it seems. Basically, we'd need to freeze the master through the whole > release process, etc. With all 1.2.1 patches on master we can just > merge them into 1.2 and have the sweet time releasing 1.2.1 without > blocking anything. > > It doesn't mean we have to support 1.2.* unless we want to and have > resources, but just from the pure technical standpoint it seems > easier. But I am ok either way. > > Cos > > -- > Take care, > Konstantin (Cos) Boudnik > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > > Disclaimer: Opinions expressed in this email are those of the author, > and do not necessarily represent the views of any company the author > might be affiliated with at the moment of writing. > > > On Sun, Jun 25, 2017 at 10:54 AM, Evans Ye <[email protected]> wrote: > > Hi all, > > > > Olaf asked on slack that how do we do 1.2.1 release when there's no patch > > goes in 1.2-branch and most on the patches for 1.2.1 are on master. > > > > My thinking is directly release 1.2.1 version from master, with following > > reasons: > > > > 1. We did not bump master to 1.3.0-SNAPSHOT > > 2. With small number of components upgraded we can say it's a minor > version > > release for bigtop. We've discussed this to meet the goal of release > > earlier, release often. > > 3. it seems most of the 1.3 fixed issues[1] can also reside in 1.2.1 > except > > Debian-9 support, which may or may not be excluded because it's quite > > independent. > > 4. We don't have too much resource to maintain two release lines. We > shall > > better keep it simple as long as it's still a reasonable way. > > > > We're close to the end of June so I'll start to prepare the release. For > > those doc related JIRAs, I'll try to get them polished before the > release. > > Please help me to get the others fixed if you've some free cycles :) > > > > [1]. https://s.apache.org/byeu > > > > > > > > 2017-05-29 21:05 GMT+08:00 Arnaud Launay <[email protected]>: > > > >> Le Mon, May 29, 2017 at 10:24:34AM +0800, Evans Ye a écrit: > >> > Surely we can add Solr 6.5.1(BIGTOP-2784) to 1.2.1 release. Do > >> > you have time to get it to the finish line recently? > >> > >> Unfortunately, I don't have enough knowledge about it to really > >> understand what's needed and what's not, the install.sh I have > >> edited so far is mostly "err, this file doesn't exist anymore, > >> let's comment the line to let the compilation continue". > >> > >> So I do have a compiling solr 6, but I'm fairly certain the > >> generated packages are incomplete :/ > >> > >> Arnaud. > >> >
