[RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

Hey folks,

I've been doing a bit of thinking about the way we handle our new timed
based released, and I've come to the conclusion that doing a vote on the
3rd Tuesday of every month is a flawed approach.

There are delays in testing, and oftentimes multiple vote rounds. This will
consistently result in the situation where we are doing the actual release
several weeks behind schedule. The result being that, according to the
calendar, I would be doing another vote perhaps a week, or even days after
the release. This clearly makes no sense.

So, I am proposing that we attempt to do a new release four weeks after the
last release.

i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
another release in three weeks.

This means that even if it takes us several weeks to do the next one, we
will then set a 4 week timer at whatever point we manage to make the
successful release.

I believe this properly accounts for the fact that we are a volunteer
project, and that sometimes, things just take a while. But it also keeps us
on a time based schedule.

One other change I am proposing: I think that in three weeks, we should cut
whatever is ready. If that means a major point revision, so be it. Minor,
so be it. Patch, so be it. Whatever is ready. No artificial "patch
release", "patch release", "feature release" dance.

Assuming nobody objects, or has a better way of doing it, I will proceed
with this idea.

You can consider this notice that I plan to start a release vote thread on
the Tuesday the 24th of July. So you have three weeks to get your features
into master.

Thanks,

-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Alexander Shorin <kx...@gmail.com>]

Noah,

Thanks for making things clear, I've nothing to add and I see the
plan. I'm  +1 to your proposal.
--
,,,^..^,,,


On Fri, Jul 5, 2013 at 5:20 PM, Noah Slater <ns...@apache.org> wrote:
> Thanks for your mail, Alex! You raise some great points.
>
> On 4 July 2013 19:58, Alexander Shorin <kx...@gmail.com> wrote:
>
>> At the moment of release point master's features might not be actually
>> ready for release due to lack of testing, docs or something.
>
>
> This is why I am hoping someone can really take ownership of the Git
> workflow stuff and drive it to conclusion. Because one of the things we
> want to introduce is that you do not merge to master until there are tests,
> docs, etc. In fact, merges to master are done via lazy consensus on the
> list. So we will all get a chance to object to something landing.
>
> Ok, not good example, but I think idea is clear: make release
>> because time is over and feature is not fixed is not good.
>>
>
> These features should be done in branches. Things should only land on
> master when they are complete, with tests, and docs.
>
>
>> I fear that it would be very easy to run into version racing while
>> nothing interesting these release will provides. If we aims to provide
>> something new with each release, probably better to drop patch version
>> number at all.
>>
>
> We're not aiming to do anything other than ship what is ready, on a regular
> basis. And that means that our releases will become smaller, and
> more manageable. And this will be a good thing overall.
>
>
>> Another problem that it would be easily to make 2-3-4 major releases
>> every 4 weeks just because they are ready - this brings compatibility
>> hell and users will reasonable to ask "why I have to use latest
>> version when they breaking things every month? I'll better stay on 1.3
>> - it's stable enough and fulfils my remeasurement".
>>
>
> Not necessarily. We really shouldn't be making breaking changes every
> month. We should be planning them as a team and landing them in batches,
> spaced out, so as not to tax the community. Nothing about the release
> procedure I have proposed changes that, or makes it any harder to do.
>
>
>> But what's the git workflow for such schedule? I see very seductive
>> reason to commit all to master to have this time based releases really
>> featured and look not so bad while been compared with 1.2 and 1.3
>> (just take a look one more time on their release notes).
>>
>
> I see what you're saying, but I don't think anybody feels this pressure. In
> fact, part of the goal here is to make the releases smaller and
> more manageable  Though, I have to say, if this spurs people on to get
> features ready and to merge them in to master, then that sounds awesome to
> me.
>
> Of course, I wouldn't want things being merged in that weren't ready, but
> as I mention, all merges to master should be done with a lazy consensus
> thread posted to dev@, that details what the feature is, what tests there
> are, and what the docs are like. This is your chance to object, if the
> feature is only half baked, or needs to be held back.
>
>
>> I think this schedule need to be heavy integrated with git workflow.
>> For instance, the rule (see [DISCUSS] Git workflow thread):
>>
>> > Master is always releasable. All work occurs on feature or fix
>> > branches and is merged to master only after tests confirm that it
>> > works.
>>
>> will help a lot to solve problems above. After 4 weeks when time is
>> over, RM requests for list of all feature-fix branches that are ready
>> for merge, merging, one week for final testing (might not be always
>> required, but still this option requires to be announced) and then cut
>> the new release bumping version number in right way (major, minor or
>> patch).
>>
>
> There's no reason to batch that merges for the last week. The merges should
> be happening as and when they are ready. In fact, I would be quite
> concerned that if we held them all back until the week before the last
> release, we are introducing a bottleneck. Also consider that we are a
> volunteer organisation, and so people are free for this sort of activity as
> an when their lives permit. It's not something we can reliably hope to
> schedule for a single week.
>
> On other hand, I agree that features shouldn't wait a years for the
>> release and releases might be a bit often, but I also think that this
>> process should be described in details to solve edge cases.
>>
>
> There's no way we can exhaustively document the whole thing up front. Well,
> we could, but I think we'd find that it doesn't match reality. What we
> should be aiming for is iterative understanding and improvement of the
> process.
>
>
>> P.S. No offence, just a thoughts (:
>>
>
> No offence taken at all. Thank you for your constructive email.
>
> I think that if you consider the proposed Git workflow, then most of your
> concerns (which are entirely valid) become non-issues. And I'm interested
> to here if you think that is the case also.
>
> I will take this opportunity to plead with the community again: we need
> somebody to take ownership of the Git workflow stuff, to look over the
> discussion, figure out a single proposal, and bring it to the community for
> a quick vote.
>
> I want to switch to this master branch based release process, and it very
> much relies on "no merges to master until the feature is complete with
> tests and docs" part of the proposal, so we need to make official as soon
> as possible!
>
> --
> NS

Re: [RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

Thanks for your mail, Alex! You raise some great points.

On 4 July 2013 19:58, Alexander Shorin <kx...@gmail.com> wrote:

> At the moment of release point master's features might not be actually
> ready for release due to lack of testing, docs or something.


This is why I am hoping someone can really take ownership of the Git
workflow stuff and drive it to conclusion. Because one of the things we
want to introduce is that you do not merge to master until there are tests,
docs, etc. In fact, merges to master are done via lazy consensus on the
list. So we will all get a chance to object to something landing.

Ok, not good example, but I think idea is clear: make release
> because time is over and feature is not fixed is not good.
>

These features should be done in branches. Things should only land on
master when they are complete, with tests, and docs.


> I fear that it would be very easy to run into version racing while
> nothing interesting these release will provides. If we aims to provide
> something new with each release, probably better to drop patch version
> number at all.
>

We're not aiming to do anything other than ship what is ready, on a regular
basis. And that means that our releases will become smaller, and
more manageable. And this will be a good thing overall.


> Another problem that it would be easily to make 2-3-4 major releases
> every 4 weeks just because they are ready - this brings compatibility
> hell and users will reasonable to ask "why I have to use latest
> version when they breaking things every month? I'll better stay on 1.3
> - it's stable enough and fulfils my remeasurement".
>

Not necessarily. We really shouldn't be making breaking changes every
month. We should be planning them as a team and landing them in batches,
spaced out, so as not to tax the community. Nothing about the release
procedure I have proposed changes that, or makes it any harder to do.


> But what's the git workflow for such schedule? I see very seductive
> reason to commit all to master to have this time based releases really
> featured and look not so bad while been compared with 1.2 and 1.3
> (just take a look one more time on their release notes).
>

I see what you're saying, but I don't think anybody feels this pressure. In
fact, part of the goal here is to make the releases smaller and
more manageable  Though, I have to say, if this spurs people on to get
features ready and to merge them in to master, then that sounds awesome to
me.

Of course, I wouldn't want things being merged in that weren't ready, but
as I mention, all merges to master should be done with a lazy consensus
thread posted to dev@, that details what the feature is, what tests there
are, and what the docs are like. This is your chance to object, if the
feature is only half baked, or needs to be held back.


> I think this schedule need to be heavy integrated with git workflow.
> For instance, the rule (see [DISCUSS] Git workflow thread):
>
> > Master is always releasable. All work occurs on feature or fix
> > branches and is merged to master only after tests confirm that it
> > works.
>
> will help a lot to solve problems above. After 4 weeks when time is
> over, RM requests for list of all feature-fix branches that are ready
> for merge, merging, one week for final testing (might not be always
> required, but still this option requires to be announced) and then cut
> the new release bumping version number in right way (major, minor or
> patch).
>

There's no reason to batch that merges for the last week. The merges should
be happening as and when they are ready. In fact, I would be quite
concerned that if we held them all back until the week before the last
release, we are introducing a bottleneck. Also consider that we are a
volunteer organisation, and so people are free for this sort of activity as
an when their lives permit. It's not something we can reliably hope to
schedule for a single week.

On other hand, I agree that features shouldn't wait a years for the
> release and releases might be a bit often, but I also think that this
> process should be described in details to solve edge cases.
>

There's no way we can exhaustively document the whole thing up front. Well,
we could, but I think we'd find that it doesn't match reality. What we
should be aiming for is iterative understanding and improvement of the
process.


> P.S. No offence, just a thoughts (:
>

No offence taken at all. Thank you for your constructive email.

I think that if you consider the proposed Git workflow, then most of your
concerns (which are entirely valid) become non-issues. And I'm interested
to here if you think that is the case also.

I will take this opportunity to plead with the community again: we need
somebody to take ownership of the Git workflow stuff, to look over the
discussion, figure out a single proposal, and bring it to the community for
a quick vote.

I want to switch to this master branch based release process, and it very
much relies on "no merges to master until the feature is complete with
tests and docs" part of the proposal, so we need to make official as soon
as possible!

-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Alexander Shorin <kx...@gmail.com>]

I have a bit opposite and pessimistic view if you don't mind (:

I see one fundamental bug of such schedule: there is no control on
features at master branch.

It will be very easy to commit new feature while this would be the
only one for the whole 4 weeks. So we have bump feature version number
and release notes would looks a bit foolish since previous 1.2 and 1.3
releases had provided much, much more than just a single feature and
few patches.

At the moment of release point master's features might not be actually
ready for release due to lack of testing, docs or something. Currently
we have public_fields feature, but it brings security (imho, since,
for example, with enabling this feature you should through away idea
to have email-based logins because all of them will be in public)
issues. Ok, not good example, but I think idea is clear: make release
because time is over and feature is not fixed is not good.

I fear that it would be very easy to run into version racing while
nothing interesting these release will provides. If we aims to provide
something new with each release, probably better to drop patch version
number at all.

Another problem that it would be easily to make 2-3-4 major releases
every 4 weeks just because they are ready - this brings compatibility
hell and users will reasonable to ask "why I have to use latest
version when they breaking things every month? I'll better stay on 1.3
- it's stable enough and fulfils my remeasurement".

But what's the git workflow for such schedule? I see very seductive
reason to commit all to master to have this time based releases really
featured and look not so bad while been compared with 1.2 and 1.3
(just take a look one more time on their release notes).

I think this schedule need to be heavy integrated with git workflow.
For instance, the rule (see [DISCUSS] Git workflow thread):

> Master is always releasable. All work occurs on feature or fix
> branches and is merged to master only after tests confirm that it
> works.

will help a lot to solve problems above. After 4 weeks when time is
over, RM requests for list of all feature-fix branches that are ready
for merge, merging, one week for final testing (might not be always
required, but still this option requires to be announced) and then cut
the new release bumping version number in right way (major, minor or
patch).

On other hand, I agree that features shouldn't wait a years for the
release and releases might be a bit often, but I also think that this
process should be described in details to solve edge cases.

P.S. No offence, just a thoughts (:

--
,,,^..^,,,


On Wed, Jul 3, 2013 at 8:13 PM, Noah Slater <ns...@apache.org> wrote:
> Hey folks,
>
> I've been doing a bit of thinking about the way we handle our new timed
> based released, and I've come to the conclusion that doing a vote on the
> 3rd Tuesday of every month is a flawed approach.
>
> There are delays in testing, and oftentimes multiple vote rounds. This will
> consistently result in the situation where we are doing the actual release
> several weeks behind schedule. The result being that, according to the
> calendar, I would be doing another vote perhaps a week, or even days after
> the release. This clearly makes no sense.
>
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.
>
> i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
> another release in three weeks.
>
> This means that even if it takes us several weeks to do the next one, we
> will then set a 4 week timer at whatever point we manage to make the
> successful release.
>
> I believe this properly accounts for the fact that we are a volunteer
> project, and that sometimes, things just take a while. But it also keeps us
> on a time based schedule.
>
> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it. Minor,
> so be it. Patch, so be it. Whatever is ready. No artificial "patch
> release", "patch release", "feature release" dance.
>
> Assuming nobody objects, or has a better way of doing it, I will proceed
> with this idea.
>
> You can consider this notice that I plan to start a release vote thread on
> the Tuesday the 24th of July. So you have three weeks to get your features
> into master.
>
> Thanks,
>
> --
> NS

Re: [RELEASE][PROPOSAL] New release schedule

[Dave Cottlehuber <dc...@jsonified.com>]

On 3 July 2013 18:13, Noah Slater <ns...@apache.org> wrote:
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.

Great idea Noah!

It sounds good to me, I think this will be A Good Thing. I can even
mark the date in my calendar so I have my stuff ready.

A+
Dave

Re: [RELEASE][PROPOSAL] New release schedule

[Russell Branca <ch...@apache.org>]

Just throwing this idea out there, but what about padding the release by a
month, but starting the release process at the same time? This gives the
benefit of having of having fixed time range releases, but also gives a
month of padding for any issues that come up with the release process. Like
I said, I'm just throwing this idea out there, haven't fully thought it
through, but I'm +1 to either this approach or the approach you outlined
above.


-Russell


On Wed, Jul 3, 2013 at 12:57 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <ns...@apache.org> wrote:
> > Yep. One that date we can look at master and see what we have. If we have
> > any features, then we bump the minor version. If we have anything that
> > breaks backwards compatibility, then we bump the major.
>
> So that means we have no guarantees of any kind on how long we go
> between feature releases, which also means our shortest possible
> maintenance window for old release might be something like 8-10 weeks?
>
> I mean, personally I'm fine with this, I always keep up to date with
> the latest release anyway. But what you're proposing here seems like a
> somewhat big deal for those slightly more enterprisey types who like
> themselves some stability, instead of forcing to be upgraded to a
> release with new features (and consequently, new bugs).
>
> Cheers,
>
> Dirkjan
>

Re: [RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

On 3 July 2013 20:57, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> So that means we have no guarantees of any kind on how long we go
> between feature releases


We didn't anyway. If there were no features ready for a feature release
window, we'd do a patch release. The only thing the release procedure can
ever do is *delay* the release of features.

which also means our shortest possible
> maintenance window for old release might be something like 8-10 weeks?
>

Not sure what to do about this. Perhaps we support major versions for 12
months. Thoughts?

(There should be no reason to support minor versions.)

I mean, personally I'm fine with this, I always keep up to date with
> the latest release anyway. But what you're proposing here seems like a
> somewhat big deal for those slightly more enterprisey types who like
> themselves some stability, instead of forcing to be upgraded to a
> release with new features (and consequently, new bugs).
>

Perhaps we're talking cross-wires here, but I don't see this. Do my
comments above clear things up?

-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Russell Branca <ch...@apache.org>]

On Thu, Jul 4, 2013 at 6:43 AM, Noah Slater <ns...@apache.org> wrote:

> Russell, I thought about padding too. But there's just no way I think I can
> get it to work without putting undue stress on me, or on the community.
> Padding would also mean that we were trying to do two releases at any one
> point. The release who's window was about the close, and the release who's
> window was a month away from starting. The only real way to add padding
> would be to make the releases happen X months apart, where X is the max
> value of "delay" we expect to experience. But if you look at the 1.3.0
> release, X was six months.
>
> So I figure that delays happen. We're a volunteer community, and sometimes
> we hit a really thorny problem. The release procedure should embrace this
> fact, instead of trying to paper over it.
>
> As with most things we do, this should a simple change that we can reverse
> if it doesn't work out for us.
>
> Jan, agreed. We should agree on a support plan up front.
>
> Is this what you are suggesting:
>
>  * N-1 for major version numbers. So if we're on 3.x, then we
> will back-port to 2.x where possible. But not 1.x.
>
> I am not sure there's any need for LTS in that scenario. For instance, when
> we bump to 2.x (hopefully this year) then we're saying, according to the
> scheme above, that 1.x will be supported for 12 months.
>
> Is there any circumstance that would not be covered by N-1 for major
> version numbers?
>
> Also, what do we mean by support? That we'll backport features and
> bugfixes? Just bugfixes?
>
> I am asking from an RM point of view, because once we bump to 2.x, our
> support plan will have a major impact on our release schedule. It might
> mean, for instance, that for every regular release we do, we have to do a
> 1.x legacy release.
>
> I worry that this could become burdensome  Perhaps we ought to stagger it
> out. So, hmm. We could do regular release every other month, and then a
> support release every other month. Just alternate them.
>
> As long as we were only ever supporting N-1 major version numbers, this
> release pattern would work for us forever.
>
>
> On 4 July 2013 10:50, Jan Lehnardt <ja...@apache.org> wrote:
>
> >
> > On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> >
> > > On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <ns...@apache.org>
> wrote:
> > >> Yep. One that date we can look at master and see what we have. If we
> > have
> > >> any features, then we bump the minor version. If we have anything that
> > >> breaks backwards compatibility, then we bump the major.
> > >
> > > So that means we have no guarantees of any kind on how long we go
> > > between feature releases, which also means our shortest possible
> > > maintenance window for old release might be something like 8-10 weeks?
> > >
> > > I mean, personally I'm fine with this, I always keep up to date with
> > > the latest release anyway. But what you're proposing here seems like a
> > > somewhat big deal for those slightly more enterprisey types who like
> > > themselves some stability, instead of forcing to be upgraded to a
> > > release with new features (and consequently, new bugs).
> >
> > We haven’t defined this properly, but we want to designate certain
> > releases to be Long Term Support (LTS) releases, that are supported
> > at least for a year, regardless of the N-1 support for regular
> > releases.
> >
> > I’d say the last 1.x.y release before 2.0.0 should be our first LTS
> > release.
> >
> > * * *
> >
> > +1 on Noah’s proposal.
> >
> > Best
> > Jan
> > --
> >
> >
> >
>
>
> --
> NS
>

Thanks for the response Noah. The releases are definitely time consuming,
so do what makes that the simplest and least stressful for you. +1 to your
proposal.


-Russell

Re: [RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

Russell, I thought about padding too. But there's just no way I think I can
get it to work without putting undue stress on me, or on the community.
Padding would also mean that we were trying to do two releases at any one
point. The release who's window was about the close, and the release who's
window was a month away from starting. The only real way to add padding
would be to make the releases happen X months apart, where X is the max
value of "delay" we expect to experience. But if you look at the 1.3.0
release, X was six months.

So I figure that delays happen. We're a volunteer community, and sometimes
we hit a really thorny problem. The release procedure should embrace this
fact, instead of trying to paper over it.

As with most things we do, this should a simple change that we can reverse
if it doesn't work out for us.

Jan, agreed. We should agree on a support plan up front.

Is this what you are suggesting:

 * N-1 for major version numbers. So if we're on 3.x, then we
will back-port to 2.x where possible. But not 1.x.

I am not sure there's any need for LTS in that scenario. For instance, when
we bump to 2.x (hopefully this year) then we're saying, according to the
scheme above, that 1.x will be supported for 12 months.

Is there any circumstance that would not be covered by N-1 for major
version numbers?

Also, what do we mean by support? That we'll backport features and
bugfixes? Just bugfixes?

I am asking from an RM point of view, because once we bump to 2.x, our
support plan will have a major impact on our release schedule. It might
mean, for instance, that for every regular release we do, we have to do a
1.x legacy release.

I worry that this could become burdensome  Perhaps we ought to stagger it
out. So, hmm. We could do regular release every other month, and then a
support release every other month. Just alternate them.

As long as we were only ever supporting N-1 major version numbers, this
release pattern would work for us forever.


On 4 July 2013 10:50, Jan Lehnardt <ja...@apache.org> wrote:

>
> On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
> > On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <ns...@apache.org> wrote:
> >> Yep. One that date we can look at master and see what we have. If we
> have
> >> any features, then we bump the minor version. If we have anything that
> >> breaks backwards compatibility, then we bump the major.
> >
> > So that means we have no guarantees of any kind on how long we go
> > between feature releases, which also means our shortest possible
> > maintenance window for old release might be something like 8-10 weeks?
> >
> > I mean, personally I'm fine with this, I always keep up to date with
> > the latest release anyway. But what you're proposing here seems like a
> > somewhat big deal for those slightly more enterprisey types who like
> > themselves some stability, instead of forcing to be upgraded to a
> > release with new features (and consequently, new bugs).
>
> We haven’t defined this properly, but we want to designate certain
> releases to be Long Term Support (LTS) releases, that are supported
> at least for a year, regardless of the N-1 support for regular
> releases.
>
> I’d say the last 1.x.y release before 2.0.0 should be our first LTS
> release.
>
> * * *
>
> +1 on Noah’s proposal.
>
> Best
> Jan
> --
>
>
>


-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Jan Lehnardt <ja...@apache.org>]

On Jul 3, 2013, at 21:57 , Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <ns...@apache.org> wrote:
>> Yep. One that date we can look at master and see what we have. If we have
>> any features, then we bump the minor version. If we have anything that
>> breaks backwards compatibility, then we bump the major.
> 
> So that means we have no guarantees of any kind on how long we go
> between feature releases, which also means our shortest possible
> maintenance window for old release might be something like 8-10 weeks?
> 
> I mean, personally I'm fine with this, I always keep up to date with
> the latest release anyway. But what you're proposing here seems like a
> somewhat big deal for those slightly more enterprisey types who like
> themselves some stability, instead of forcing to be upgraded to a
> release with new features (and consequently, new bugs).

We haven’t defined this properly, but we want to designate certain
releases to be Long Term Support (LTS) releases, that are supported
at least for a year, regardless of the N-1 support for regular
releases.

I’d say the last 1.x.y release before 2.0.0 should be our first LTS
release.

* * *

+1 on Noah’s proposal.

Best
Jan
--

Re: [RELEASE][PROPOSAL] New release schedule

[Dirkjan Ochtman <di...@ochtman.nl>]

On Wed, Jul 3, 2013 at 9:45 PM, Noah Slater <ns...@apache.org> wrote:
> Yep. One that date we can look at master and see what we have. If we have
> any features, then we bump the minor version. If we have anything that
> breaks backwards compatibility, then we bump the major.

So that means we have no guarantees of any kind on how long we go
between feature releases, which also means our shortest possible
maintenance window for old release might be something like 8-10 weeks?

I mean, personally I'm fine with this, I always keep up to date with
the latest release anyway. But what you're proposing here seems like a
somewhat big deal for those slightly more enterprisey types who like
themselves some stability, instead of forcing to be upgraded to a
release with new features (and consequently, new bugs).

Cheers,

Dirkjan

Re: [RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

Yep. One that date we can look at master and see what we have. If we have
any features, then we bump the minor version. If we have anything that
breaks backwards compatibility, then we bump the major.

I am happy to handhold anybody if they would like to try doing a release. I
think it's important for the project that as many people as possible feel
comfortable doing them.


On 3 July 2013 17:55, Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Wed, Jul 3, 2013 at 6:13 PM, Noah Slater <ns...@apache.org> wrote:
> > So, I am proposing that we attempt to do a new release four weeks after
> the
> > last release.
>
> +1.
>
> > One other change I am proposing: I think that in three weeks, we should
> cut
> > whatever is ready. If that means a major point revision, so be it. Minor,
> > so be it. Patch, so be it. Whatever is ready. No artificial "patch
> > release", "patch release", "feature release" dance.
>
> I'm not sure how that works. Are we going to work only on master and
> make it a feature release if we have any new features after 4 weeks?
>
> Also, I'm itching to help out with RMing so it doesn't block on so few
> people.
>
> Cheers,
>
> Dirkjan
>



-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Dirkjan Ochtman <di...@ochtman.nl>]

On Wed, Jul 3, 2013 at 6:13 PM, Noah Slater <ns...@apache.org> wrote:
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.

+1.

> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it. Minor,
> so be it. Patch, so be it. Whatever is ready. No artificial "patch
> release", "patch release", "feature release" dance.

I'm not sure how that works. Are we going to work only on master and
make it a feature release if we have any new features after 4 weeks?

Also, I'm itching to help out with RMing so it doesn't block on so few people.

Cheers,

Dirkjan

Re: [RELEASE][PROPOSAL] New release schedule

[Garren Smith <ga...@apache.org>]

I'm +1 on this idea. I think it will keep the release process moving nicely.

On 03 Jul 2013, at 6:13 PM, Noah Slater <ns...@apache.org> wrote:

> Hey folks,
> 
> I've been doing a bit of thinking about the way we handle our new timed
> based released, and I've come to the conclusion that doing a vote on the
> 3rd Tuesday of every month is a flawed approach.
> 
> There are delays in testing, and oftentimes multiple vote rounds. This will
> consistently result in the situation where we are doing the actual release
> several weeks behind schedule. The result being that, according to the
> calendar, I would be doing another vote perhaps a week, or even days after
> the release. This clearly makes no sense.
> 
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.
> 
> i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
> another release in three weeks.
> 
> This means that even if it takes us several weeks to do the next one, we
> will then set a 4 week timer at whatever point we manage to make the
> successful release.
> 
> I believe this properly accounts for the fact that we are a volunteer
> project, and that sometimes, things just take a while. But it also keeps us
> on a time based schedule.
> 
> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it. Minor,
> so be it. Patch, so be it. Whatever is ready. No artificial "patch
> release", "patch release", "feature release" dance.
> 
> Assuming nobody objects, or has a better way of doing it, I will proceed
> with this idea.
> 
> You can consider this notice that I plan to start a release vote thread on
> the Tuesday the 24th of July. So you have three weeks to get your features
> into master.
> 
> Thanks,
> 
> -- 
> NS

Re: [RELEASE][PROPOSAL] New release schedule

[Noah Slater <ns...@apache.org>]

Hehe...


On 3 July 2013 17:37, Robert Newson <rn...@apache.org> wrote:

> +1. Also, the 24th of July is my birthday so I might not vote on the
> day itself. Don't be angry.
>
> B.
>
>
> On 3 July 2013 17:13, Noah Slater <ns...@apache.org> wrote:
> > Hey folks,
> >
> > I've been doing a bit of thinking about the way we handle our new timed
> > based released, and I've come to the conclusion that doing a vote on the
> > 3rd Tuesday of every month is a flawed approach.
> >
> > There are delays in testing, and oftentimes multiple vote rounds. This
> will
> > consistently result in the situation where we are doing the actual
> release
> > several weeks behind schedule. The result being that, according to the
> > calendar, I would be doing another vote perhaps a week, or even days
> after
> > the release. This clearly makes no sense.
> >
> > So, I am proposing that we attempt to do a new release four weeks after
> the
> > last release.
> >
> > i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
> > another release in three weeks.
> >
> > This means that even if it takes us several weeks to do the next one, we
> > will then set a 4 week timer at whatever point we manage to make the
> > successful release.
> >
> > I believe this properly accounts for the fact that we are a volunteer
> > project, and that sometimes, things just take a while. But it also keeps
> us
> > on a time based schedule.
> >
> > One other change I am proposing: I think that in three weeks, we should
> cut
> > whatever is ready. If that means a major point revision, so be it. Minor,
> > so be it. Patch, so be it. Whatever is ready. No artificial "patch
> > release", "patch release", "feature release" dance.
> >
> > Assuming nobody objects, or has a better way of doing it, I will proceed
> > with this idea.
> >
> > You can consider this notice that I plan to start a release vote thread
> on
> > the Tuesday the 24th of July. So you have three weeks to get your
> features
> > into master.
> >
> > Thanks,
> >
> > --
> > NS
>



-- 
NS

Re: [RELEASE][PROPOSAL] New release schedule

[Robert Newson <rn...@apache.org>]

+1. Also, the 24th of July is my birthday so I might not vote on the
day itself. Don't be angry.

B.


On 3 July 2013 17:13, Noah Slater <ns...@apache.org> wrote:
> Hey folks,
>
> I've been doing a bit of thinking about the way we handle our new timed
> based released, and I've come to the conclusion that doing a vote on the
> 3rd Tuesday of every month is a flawed approach.
>
> There are delays in testing, and oftentimes multiple vote rounds. This will
> consistently result in the situation where we are doing the actual release
> several weeks behind schedule. The result being that, according to the
> calendar, I would be doing another vote perhaps a week, or even days after
> the release. This clearly makes no sense.
>
> So, I am proposing that we attempt to do a new release four weeks after the
> last release.
>
> i.e. We released 1.3.1 1 week ago, so I am proposing that we attempt
> another release in three weeks.
>
> This means that even if it takes us several weeks to do the next one, we
> will then set a 4 week timer at whatever point we manage to make the
> successful release.
>
> I believe this properly accounts for the fact that we are a volunteer
> project, and that sometimes, things just take a while. But it also keeps us
> on a time based schedule.
>
> One other change I am proposing: I think that in three weeks, we should cut
> whatever is ready. If that means a major point revision, so be it. Minor,
> so be it. Patch, so be it. Whatever is ready. No artificial "patch
> release", "patch release", "feature release" dance.
>
> Assuming nobody objects, or has a better way of doing it, I will proceed
> with this idea.
>
> You can consider this notice that I plan to start a release vote thread on
> the Tuesday the 24th of July. So you have three weeks to get your features
> into master.
>
> Thanks,
>
> --
> NS