couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [RELEASE][PROPOSAL] New release schedule
Date Fri, 05 Jul 2013 13:20:52 GMT
Thanks for your mail, Alex! You raise some great points.

On 4 July 2013 19:58, Alexander Shorin <> 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

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

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message