couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: [RELEASE][PROPOSAL] New release schedule
Date Thu, 04 Jul 2013 18:58:37 GMT
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

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 <> 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

View raw message