On 08/19/2016 04:20 AM, Stef Walter wrote: > On 18.08.2016 22:12, Josh Berkus wrote: >> On 08/18/2016 02:24 AM, Stef Walter wrote: >>> Yesterday several of us (roughly the top contributors [1] to Cockpit) >>> discussed removing the '0.x' from the Cockpit version number. >>> >>> The plan is from here on out to just go with integer versions, starting >>> with version '118' following version '0.117'. >>> >>> Cockpit releases weekly. Some versions of Linux distributions closely >>> track that weekly release. Other choose particular releases to include, >>> based on features and other criteria. >>> >>> Cockpit now has a stable javascript API and file layout for components >>> [2], as well as backwards compatible transport protocol. I hope to post >>> more documentation about these guarantees soon. >> >> What about making a 1.0 release? > > That's a good question. But let me turn it around. What would the > benefit of 1.0 be? > > Cockpit uses continuous integration and delivery. We deliver every week, > and most of them are solid and stable. Certain Linux distributions track > the weekly updates, others pick certain releases and avoid churn for > those users. > > So the numbers go up regularly. What would the benefit of having numbers > like "1.110" or "1.202" really be? > > I like the systemd or CoreOS model for a project like Cockpit. Cockpit > integrates the system, updates steadily as the system changes, and isn't > a library or API. > > But if you have reasons not to do that, I'd love to hear them. >
Well, one of the fundamental problems with going to a whole-integer release number is that it basically doesn't provide you with any opportunity to change your mind. Once you move to version 118, there's no way to revert to saying "Man, I really wish we had a way to say that *this* release was a better one for those distros that pick one and avoid churn". Because if you decided to go back to a major.minor.patch style release, it's going to have to start at 119.0.0 (or else rename the project to go back to 1.0.0, for those distros that don't have something like epoch to deal with it). There are other, non-technical benefits to a more traditional version scheme. For example, there is a very human response to seeing anything move from 0.x to 1.x. The sense there is that the project has *arrived*. Furthermore, a major version number jump provides a clear notification to tech press that it's a good time to do a re-review and talk about it again. If you make the shift to whole-version numbers, you'll get exactly one more of these short of sending people out to actually talk to journalists (or writing really compelling content for distro release announcements, but those will end up promoting the distro, not the project). We saw this with NetworkManager... when it finally moved to the 1.x series, all of the major news sites immediately went back and did brand new reviews and perceived it as finally "ready". It didn't matter that the project had been functional and stable for years before that; the move to 1.0 provided a significant opportunity for press and to let people see that they should come back and give it another look. Crazily enough, the number of cargo-cult "never use NetworkMangler(sic)" posts dropped enormously after the 1.0 release because people came back and tried it again. I'd actually disagree with making Cockpit 1.0 at this particular moment. I think it has come a long way, is very stable and it is a great piece of software. However, I also think that the optimum 1.0 point would have been when the API and transport protocol went stable. That would have been a very clear delineation. So my thoughts right now are that Cockpit should wait a while longer until it's about to land some truly killer feature (maybe the Ansible Galaxy stuff that came up at Flock?) and declare *that* a 1.0 release.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
