Christian Robottom Reis
kiko at async.com.br
Mon Dec 15 20:20:30 UTC 2003
On Mon, Dec 15, 2003 at 09:49:38PM +0200, Jouni Heikniemi wrote:
> > > So just before each major stable release, we bump the major number of
> > > the template versions on every template which has changed at all (which
> > > will be most or all of them.) After that, we use minor numbers on the
> > > branch.
> I agree that it sounds like a usable solution. Though, do I understand
> correctly that the semantics assigned for major and minor version numbers*
> would then no longer apply? Because there's no way to guarantee that
> changes in a stable branch wouldn't be interface-breaking...
Really? I would think all changes in the stable branch would be
backwards-compatible, to ensure that customized templates would work
over the whole branch's lifetime. Doesn't our 2.16 experience confirm
> *) From bug 140527 comment 1:
> "If the major part changes, that means the interface to this template is
> incompatible with the interface to previous templates. Bugzilla will note
> this incompatibility and tell you about it.
> If the minor part changes, the interface is backwardly-compatible, but
> there are some changes you should investigate and consider also making in
> your custom templates."
My suggestion for this is the following:
We push up version numbers for template changes inside the stable
branch. The changes accepted *should only be minor changes*.
When the devel branch ships [*] -- IOW, when it becomes the next
stable branch -- push the major version up one notch from the
current stable version's major.
If by any chance a catastrophic situation arises on the stable
branch which requires incompatible changes to templates, push up the
template's major number and live with the broken pieces. This is a
last-resort measure, to be sure, to be avoided at all costs.
[*] We could do this when the devel branch *opened*. However, this will
make it *impossible* to increment the major version in the stable branch
without creating serious confusion.
This does leave a loophole resulting from incompatible changes done to
a previous stable version when the next stable version has shipped. I
think the policy should be that these changes are forbidden, and users
wanting a fix should move on to the new stable version.
In practice, this implies the following actions:
- When reviewing or approving a template change on the stable
branch, ask the patch author if the template version should be
updated, and if not, why not.
- When shipping a new stable branch, do a major template version
update over all previously shipped templates.
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
More information about the developers