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