> 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
