> 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.
Hans
