[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC changes in version numbering schemes
- To: ports_(_at_)_openbsd_(_dot_)_org
- Subject: Re: RFC changes in version numbering schemes
- From: hanz_(_at_)_hanz_(_dot_)_nl
- Date: Thu, 3 Nov 2005 10:45:55 +0100 (CET)
- Importance: Normal
> In order to get you more confused, we've got more bright ideas about
> version numbering...
> Right now, we mostly use the `vendor' number scheme, and we add a simple
> p* suffix to denote what's going on with the OpenBSD port.
> As we've noticed, some times, vendor version numbers go backwards, or we
> don't plan enough in advance, and it gets confusing.
> For instance, kde uses a scheme like 3.4.3, 3.4.92, 3.5, which is fine.
> gcc is going from gcc-3.3.20050920 to gcc-3.3.6 (release).
> The idea is to add some v* suffix each time the numbering scheme changes.
> So, if pkg_add can compare version numbers on its one, we don't need any
> suffix for that.
> If it can't, then we need to bump v*. As expected, we start with an empty
> v* suffix...
> So, with that scheme, gcc would go from 3.3.20050920 to 3.3.6v0
> Some comments:
> - we still need the p* stuff to denote OpenBSD specific changes.
> - v* versions mean we can go backwards. If we find a security issue,
> and we have to go back from foo-2.0 to foo-1.9, then we just bump v* so
> that it becomes foo-1.9v0, which is higher than foo-2.0...
> The main objection you can have is that this is too complicated, but so
> far, we haven't been able to find any hole in that scheme...
> Opinions ?
It adds more complexity to already complex version numbers, but I thing it
will solve the version-problem ones and for all.
I'm all for.
Visit your host, monkey.org