On 19.08.2016 12:53, Stephen Gallagher wrote: > On 08/19/2016 04:20 AM, Stef Walter wrote: <snip> >> 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).
The "change your mind" argument is interesting. A related "change your mind" argument (apologize if I'm doing a straw man), is if we didn't actually want to stay 'stable' later and say ... "Well it turns out that we want to break everything and go to 2.0". I haven't heard any long term contributor saying they want to keep that door open. We don't want to do a python 3.x. Even if we did, renaming the package names would appropriate. In case anyone is wondering, we have avenues to track the rapid development in the javascript and operating system space, that do not involve the Cockpit version number. From the very fact that each part of Cockpit is its own bundle including its own javascript dependencies ... to the fact that the shared parts of Cockpit have been inter-operable for many releases now. However in a last resort, we can just go to the YEAR.N epoch for a version number. > 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). Dropping the 0.x accomplishes exactly the same thing here. In addition the non-technical to response to 1.0 is: I'll wait for 1.1 ... which in our case would come out a week later :S Cockpit is continuously developed, integrated, and delivered. We're able to do that with aggressive upstream testing and feedback. On busy days 10,000 of instances are started to test Cockpit changes. Out of the 50 or so releases in the past year, there's been one or two releases in the last year that were broken in a major way. So the goal of Cockpit is to be continuously developed, continuously integrated, and stable. Having versions like 1.1, 1.2, 1.3, 2.x doesn't tell that story at all. Are those ambitious goals? Yup. But it's not an arbitrary goal. People are already depending on the stability of Cockpit, and it would be a total cop-out to do an incompatible 2.x later on. > 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. So all that said, I think this is *still* something we want to do: have monotonously increasing version numbers. That said, this discussion has been good. There's a few more things we should probably do before we remove the '0.x' prefix. * Documenting exactly what is stable and what's not. * Providing a simple way (ie: other than packaging 'Requires') for Cockpit components/plugins to indicate the minimum version of Cockpit that they require. * Representing the version numbers (Cockpit is not a single entity) correctly in the javascript API and in the About dialog. None of the above require breaking compatibility, but they are finishing touches that we should have in place. Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
