Based on this discussion, I've updated RELEASE to reflect a 1 week code freeze prior to release:
https://github.com/apache/incubator-tinkerpop/blob/master/RELEASE.asciidoc#pre-flight-check We'll see this in place for the 3.1.0 release in November which means we'll see our first TinkerPop code freeze on the week of November 9th. I imagine that will be the day we create a tp31 branch. Thanks, Stephen On Fri, Oct 16, 2015 at 10:08 AM, Marko Rodriguez <okramma...@gmail.com> wrote: > Yes. > > We can't have happen AGAIN what we had happen on this release and > unfortunately, on the last release too. > > The number 1 most despicable human quality (in my book) -- > procrastination. If something is due in a year, get it done 6 months early. > If its due in a week, have it done the next day. If its due now, learn to > reverse time and get it done when the dinosaurs roamed. The date something > is due is not the date its due, its the date its late. > > With that -- we can't have people merging the night before w/o doing full > integration tests, doc builds. Its not everyone else's responsibility to > scramble to fix people's last minute problems. Get your work done early, > have it tested, have the docs building, have it all pretty and perfect for > the releaser. Nothing is more demoralizing then going to do the release > (which is demoralizing in itself) to only see that tests aren't passing, > docs aren't building… that is just straight wrong (disrespectful). > > Anything that prevents procrastinators from getting their dirty little > deranged hands on the TinkerPop flow -- I am all about it. > > Marko. > > http://markorodriguez.com > > On Oct 16, 2015, at 7:29 AM, Stephen Mallette <spmalle...@gmail.com> > wrote: > > > To improve on our release process a bit and to make things a bit less > > hectic for the "release manager" on release day I've been documenting a > few > > things I've done this week in preparation for 3.0.2. > > > > > https://github.com/apache/incubator-tinkerpop/blob/tp30/RELEASE.asciidoc#pre-flight-check > > > > I'd like to include in this list something that Matt Frantz had suggested > > when we released 3.0.1 - code freeze 1 week prior to release. To be more > > specific, I think that means that we should stop changes to actual "code" > > the day we begin the pre-flight check. Documentation tweaks and other > > knick-knacks would still be fair game, but I think we reduce some > > risk/headache by placing this limit on ourselves. > > > > So, I guess this thread is about two things: > > > > 1. What do you think of my pre-flight checks? Should anything be added? > > 2. Should we implement Matt Frantz's suggestion and institute a 1 week > code > > freeze prior to release? > >
