Quick Github milestone update

[Antonio Salazar Cardozo]

Hey folks,

As we've mentioned in the release notes for 3.1.0-M1 and M2, we've

adopted a regular bimonthly milestone release cadence. To help follow

along with this new release cadence, I've added milestones to Github

for releases through the end of the year (3.2.0-RC1 in December).

Amongst other things, I've explicitly not created milestones for final

releases; instead, the first RC of each minor release is in the milestone

list. The final release will hopefully follow shortly after that first RC, but

there's always a little bit of uncertainty there, and I wanted to make sure

the dates on there reflected the fixed points of our intended release

schedule.

Open to feedback on any of that; in the meantime, I'll probably be moving

some of the stuff I was planning on working on into some of those buckets

based on my expected availability.

Thanks,

Antonio

[Matt Farmer]

The due dates used for these releases seem off. My current calendar has the following schedule:

Lift 3.1.0-M3 — June 1

Lift 3.1.0-RC1 — June 15

Lift 3.2.0-M1 — August 1

Lift 3.2.0-M2 — October 1

Lift 3.2.0-M3 — December 1

Lift 3.2.0-RC1 — December 15

These are all calculated moving forward from a start date of February 1 this year. Even though we didn't actually hit that date for 3.1.0-M1, I think it's still the right shape of a release schedule.

To the point about RC uncertainty: I think we should consider the milestone releases and RC1 to be "train scheduled" releases. So, even if Lift 3.1.0 takes four RCs going into the middle of August, Lift 3.2.0-M1 should still go out on time around the start of August. This is a bit different than how we've done RC's in the past where we declared a merge freeze on master until things were in a final state, but it should give us the freedom to make the right choices about when to declare something "final" while maintaining forward momentum - especially in December where 3.2.0-RC1 comes out right before a long break for most folks.

Cheers,

Matt

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

On Apr 24, 2017, at 09:33, Matt Farmer <ma...@frmr.me> wrote:

The due dates used for these releases seem off. My current calendar has the following schedule:

Lift 3.1.0-M3 — June 1

Lift 3.1.0-RC1 — June 15

Lift 3.2.0-M1 — August 1

Lift 3.2.0-M2 — October 1

Lift 3.2.0-M3 — December 1

Lift 3.2.0-RC1 — December 15

Not entirely sure where that came from; all of the release listings in the ML thread

I linked are aligned to 15ths of months, including your original suggestion :) That said,

the dates are relatively arbitrary anyway, so either way works fine for me. The goal

seems like it’s to timebox, and whether we’re timeboxing on firsts-of-months or

15ths-of-months is 🤷‍♂️

To the point about RC uncertainty: I think we should consider the milestone releases and RC1 to be "train scheduled" releases. So, even if Lift 3.1.0 takes four RCs going into the middle of August, Lift 3.2.0-M1 should still go out on time around the start of August. This is a bit different than how we've done RC's in the past where we declared a merge freeze on master until things were in a final state, but it should give us the freedom to make the right choices about when to declare something "final" while maintaining forward momentum - especially in December where 3.2.0-RC1 comes out right before a long break for most folks.

The post I linked to directly mentions branching off for the RC on the RC date, and

letting master roll forward after that. Diego brought up a concern about splitting folks

on RC vs milestone, and I floated the idea that we could branch off the RC but put

a heavier weight on getting the final release finished over merging new features

into the next milestone. I don’t think that part of the discussion is necessarily 100%

settled, but I’m in a “let’s do this once or twice and see how things move” mode on

that front.

Thanks,

--

Antonio Salazar Cardozo

On twitter @lightfiend

https://keybase.io/shadowfiend

[Matt Farmer]

Uhm.

Oh. Heh. I think I was using those calendar reminders as "Start harassing folks about getting the release out" and the forgot that was the intent of the calendar reminders.

I'm good either way, too, then. < shrug >