On 10/03/2015 5:41 a.m., Alex Rousskov wrote: > On 03/07/2015 10:04 PM, Amos Jeffries wrote: > >> Proposal 2) >> >> We are developing Squid with an incremental development process. The >> initial major version number is effectively meaningless in that process. >> We should move from the major.minor.patch to just a release.patch >> numbering system. >> >> This would mean this years upcoming major series would be 4.x, and next >> years would be 5.x and so on. > > My understanding of what has been proposed as release.patch is > different: There is no artificial year boundary. If you add something > new, you increment the release (i.e., first) number. If you just fix > something old, you increment the patch (i.e., second) number.
There is approximately 8-18 months "year" between series releases now. A very arbitrary choice whenever it seems reasonable to release a batch of features. My undertanding of the proposal stated was that we keep that current practice, but dropping the 2-part "3.x" numeric down to a single part. Its already clear from past discussions that our views of "feature" are very different. If we bumped the version with each "new thing" ... ... last month we had non-trivial feature changes (100+ Lines of code) on the 26th, 22nd, and some lesser (25+ LOC) but still widely user visible new thing on the 11th and 1st, and large-ish but not user visible feature changes across the 1st-5th and 19th. That would be 4-8 major releases of Squid within the month of Feb 2015. > > The advantage is in removing a concept of a "major release" and the > often artificial boundaries associated with it. For example, you would > not have to search for an excuse to release 4.0 like you are doing now. I'm not searching for excuses. There is a meta-pattern of previous major numbers changing roughly when the language is changed. Roughly because it is +/- a few years and the next "new" language this time around can build anything 3.3+ AFAIK, while the "old" language can't build new tarballs - and there is precedence in the last changover there too with C++ tools building C code fine but _not_ vice-versa. I'm seeking opinions. On whether we continue with that pattern in conjunction with the coming trunk activity, or discard it in favour of something else - even if that something else is slipping down the slope towards an eventual 3.999 series (haven't heard anyone advocating for that though). > > The disadvantage is in removing a concept of "major upgrade pains" and > the often real boundaries associated with it. For example, it would be > more difficult for you to explain that jumping from 11.4 to 12.4 > requires a week of system administration and testing work while going > from 11.4 to 21.4 does not. > > You can still have LTS-like releases, of course. The versioning scheme > does not affect that at all. > > >> There are quite a lot of infrastructure changes involved with that big a >> change, and its not entirely clear how the beta releases would be >> represented - perhapse not having any beta releases at all? > > As Kinkie have said, you can apply the current solution for beta > releases by adding an extra number after zero. For the release.patch > scheme, betas would look like release.0.patch. > > I remain to be skeptical about the advertised correlation between our > initial stable releases and actual, real-world stability. Our official > beta process seems to mislead as much as it informs. Thus, I welcome > experiments that would get rid of that process. > > At the end of the day, versioning does not really matter much IMO. The > important things are stability and timeliness (i.e., release delay for > features in trunk) of our releases. > > > HTH, > > Alex. > Thank you for the feedback. Amos _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
