couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [RELEASE][PROPOSAL] New release schedule
Date Tue, 09 Jul 2013 00:17:44 GMT
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 <nslater@apache.org> wrote:
> Thanks for your mail, Alex! You raise some great points.
>
> On 4 July 2013 19:58, Alexander Shorin <kxepal@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

Mime
View raw message