[Opendnssec-develop] Re: Versioning scheme

[Ondřej Surý]

Yep, I agree. This is fine with me.

O.


On Thu, Mar 14, 2013 at 8:29 AM, Roland van Rijswijk - Deij <
Roland.vanRijswijk at surfnet.nl> wrote:

> Hi Sara,
>
> Apparently, no one has responded to this one yet, so: bump.
>
> My 2 cents: I have no problem with the proposed scheme.
>
> Cheers,
>
> Roland
>
> Sara Dickinson wrote:
> > Hi All,
> >
> > The development team had a discussion last year about the versioning
> scheme used for OpenDNSSEC and the general feeling was that it would make
> sense to switch from the current component based scheme to an API
> compatibility based approach. The upcoming release of 1.4 would be a
> suitable time to change the versioning scheme so I wanted to run this past
> the board to see if anyone has strong feelings either way before we go
> ahead with this. The details of the current and proposed scheme are below.
> >
> > We would obviously need to communicate this change to the users
> effectively. One impact of the change would probably be to increase the
> frequency at which the minor versions increased.  We might also have to
> review how the roadmap refers to future releases since version numbers
> would not be guaranteed (e.g. we could use names not numbers to label
> releases with specific content) and review what maintenance we provide on
> older releases too.
> >
> > Regards
> >
> > Sara.
> >
> >
> > Current scheme
> > ----------------------------
> >
> > The current version numbering system based on the following (and also
> direction from the board about what functionality they would like to see in
> what release):
> >
> > Releases are numbered using the following scheme:
> <name>-<major>.<minor>.<patch>
> >
> >       • <name> - The name of the software, e.g. opendnssec or softhsm.
> >       • <major> - Indicate changes in the overall system design.
> >       • <minor> - Indicate changes in the components.
> >       • <patch> - Indicate bug fixes.
> >
> > In practice 'patch' releases often include updates that extend (and
> sometimes change) functionality, command utilities and/or log output.
> >
> >
> > Proposed scheme
> > -----------------------------
> >
> > Something along the lines of  e.g. http://semver.org/ which summarises
> to:
> >
> >       • <name> - The name of the software, e.g. opendnssec or softhsm.
> >       • <major> - Backwards incompatible changes must increase the major
> version.
> >       • <minor> - New, backwards compatible functionality, deprecated
> functionality, or substantial new functionality within private code.
> >       • <patch> - Only backwards compatible bug fixes.
> >
> > This does assume a clearly defined API, so there is an argument for
> postponing any change until there is a unified control interface for ODS
> but for 1.4 this could be based on the command utilities and database
> schema. Note that it also doesn't explicitly exclude bumping the major
> version for major functional changes in private code.
> >
> >
> >
> >
> >
> >
>
> --
> -- Roland M. van Rijswijk - Deij
> -- SURFnet bv
> -- w: http://www.surfnet.nl/en/
> -- t: +31-30-2305388
> -- e: roland.vanrijswijk at surfnet.nl
>



-- 
Ondřej Surý <ondrej at sury.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130314/8aad83b1/attachment.htm>