Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: As a workaround to make life easier for third-party tools, the upcoming major release will be called Git 1.9.0 (not Git 1.9). The first maintenance release for it will be Git 1.9.1, and the major release after Git 1.9.0 will either be Git 2.0.0 or Git 1.10.0. Apologies if this ground has been tread before, but has there been a version numbering discussion? A quick google didn't seem to turn anything up. This seems to be an opportune time to drop the useless first digit. Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0, 3.0, 4.0, etc, with the 2nd digit would take the meaning of the current 3rd digit and so on. Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Fri, Feb 14, 2014 at 12:10:05PM -0800, Junio C Hamano wrote: Andrew Eikum aei...@codeweavers.com writes: On Wed, Feb 12, 2014 at 01:59:41PM -0800, Junio C Hamano wrote: As a workaround to make life easier for third-party tools, the upcoming major release will be called Git 1.9.0 (not Git 1.9). The first maintenance release for it will be Git 1.9.1, and the major release after Git 1.9.0 will either be Git 2.0.0 or Git 1.10.0. Apologies if this ground has been tread before, but has there been a version numbering discussion? A quick google didn't seem to turn anything up. This seems to be an opportune time to drop the useless first digit. Explicitly, the major release numbers would be: 1.8, 1.9, then 2.0, 3.0, 4.0, etc, with the 2nd digit would take the meaning of the current 3rd digit and so on. Considered, and discarded. cf. http://article.gmane.org/gmane.comp.version-control.git/241498 Thank you for the link, it hadn't turned up in my searching. When you see a version number vX.Y.0 next time, think of it as just play vX.Y without the third digit, and you will be fine. People's script cannot learn the think of it as ... part overnight, and that is why we have the .0 there. Sorry if I wasn't clear, I meant the useless digit is the first one, which is currently 1. and has been hanging around for a bit over eight years. My worry is having 2. hang around for another decade or longer. I'd rather see X.0.0 denote a major feature release (currently represented as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. So the major release version sequence would become 1.8.0, 1.9.0, 2.0.0, 3.0.0, with minor releases like 2.1.0, and bugfix releases like 2.1.1. It seems reasonable to expect fewer backwards incompatible changes in the future as Git has become more mature. This reduces the utility of reserving X.0.0 for major backwards incompatible changes, especially considering it's already been eight years for the first increment. Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)
On Fri, Feb 14, 2014 at 01:08:32PM -0800, Junio C Hamano wrote: Andrew Eikum aei...@codeweavers.com writes: My worry is having 2. hang around for another decade or longer. I'd rather see X.0.0 denote a major feature release (currently represented as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. We need three categories: (1) potentially incompatible, (2) feature, (3) fixes-only. We have been doing two levels of features by having both second and third numbers and we are flattening by removing the second one. It seems reasonable to expect fewer backwards incompatible changes in the future as Git has become more mature. This reduces the utility of reserving X.0.0 for major backwards incompatible changes, especially considering it's already been eight years for the first increment. We are not done yet, far from it. If we can stay at 2.X longer, that is a very good thing. Okay, fair enough. Thanks for explaining :) Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
