Template versioning

[Christian Robottom Reis]

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

> *) 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.

Sounds acceptable?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331