On Thu, Feb 28, 2008 at 1:32 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Once upon a time, we had a release policy [1]. It said that releases
> would be roughly time-based, that each release would include at least
> one new feature or "significant differentiator", but that we wouldn't
> say specifically which feature it would be. Whatever's ready when the
> date arrived could be the release definer. It wouldn't matter so much
> *what* the feature was, as long as there was one. After all, what
> doesn't get shipped in this release would just get shipped later.
>
> Unfortunately, we ignored this policy for 1.5.
>
> Instead, we decided that Merge Tracking would define the release.
> Then we delayed the release as long as necessary to get basic Merge
> Tracking into it, even though other features were ready earlier
> (WebDAV proxy, sparse directories, etc), or could have been ready if
> we hadn't felt such mad pressure to finish Merge Tracking because we
> decided that it -- and nothing else -- would be the release definer.
>
> Can we please, please do things the other way for 1.6?
>
> Let's say "1.6 will come out approximately six months after 1.5, and
> whatever is ready will go into it." If improved tree-conflicts are
> ready, great. If reflective merges are ready, great. If something
> else is ready, great. But -- and here's the important thing -- if
> only *one* thing is ready, the release should *not* wait for any other
> thing. At six month windows, the price of delaying a not-quite-ready
> feature is not so high, and when it does come out it will be mature.
>
> As it was, we paid both coming and going for our indiscipline: because
> we refused to release 1.5 for so long, we finally had to compromise on
> some parts of Merge Tracking in order just to ship.
>
> I know these are not new thoughts; Justin recently posted saying the
> same thing. I just thought I'd point out that we wrote up this policy
> years ago, and pretty much all thought it was a good idea, and then we
> ignored it anyway. We can stop ignoring it any time we want :-).
+1 to all of the above.
We have no rule that says we have to issue perfect releases as long as
we have a committment to do better next time. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-29 07:12:23 CET