On 09/05/2016 12:08 PM, Stef Walter wrote:
On 22.08.2016 18:25, Josh Berkus wrote:
Stef,
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.
So, I'm looking at this from an advocacy perspective.
We had more discussion about this today in our IRC meeting.
We've never had a 1.0 release. We haven't really promoted cockpit outside of the Red Hat circle.
That has indeed been a sore point. We discussed how to help Cockpit into Ubuntu's repositories as a concrete step forward.
If Cockpit is all the sudden version 118, people won't know what they're supposed to use ... and we lose an opportunity for promoting the project to external OSS communities and users.
We can promote the fact that it's no longer 0.x and has stable API, plug-ability and so on.
There's also that the other project to use whole numbers for versions, and increase them frequently, has created a bad reputation from that (Firefox). So many users' experience with large version numbers is going to be negative.
Firefox is a *great* example of what we're trying to achieve here. Ambitious as it were ... some points:
First of all I use "Firefox" and expect it to be updated regularly ... I don't use "Firefox 3.8" ... ditto for Chrome.
This is the same experience we want. Admins can use port 9090 to access an interface with the specific capabilities of that server. The version number of Cockpit itself is secondary and a diagnostic tool for when things don't function as expected..
That said, I don't disagree that this is what we want. But the version number even today is basically invisible to the *user*. It is interesting primarily to the administrator of the system (and even then, only insofar as it matches up to the feature announcement including the thing they wanted to see added).
I'd claim that this part of the argument is *irrelevant* to the discussion, because the exact nature of the version number doesn't matter as long as it is an index to a set of features (meaning that changing it from 0.x to something else would result in exactly zero change in this experience).
- Firefox won't get to say: "Oh we now have version 2.x which breaks all the (web) apps you've written so far. Too bad." That's the same goal we'd like to have for Cockpit's functionality and plugins.
Actually, they've done *exactly* this with the change in plugin and extension APIs in Firefox between releases and it has caused *enormous* headaches for many people (for example, it completely broke FreeIPA's autoconfiguration plugin, making it much harder to configure a client). There are plenty of other examples of good extensions that suddenly got broken with basically no advance knowledge of the user. Of course, then the user goes and complains to the extension writer instead...
From the perspective of the user, versions like this are "minor updates" and when things break in a minor update, they get very angry.
As time goes on grow, there will be functionality added, and other parts deprecated or removed. There are independent protocol and javascript API versioning mechanisms in place in Cockpit to account for this.
But a major break to (python) 3.x just isn't part of the plan.
Right, but the best laid plans of mice and men oft go awry...
Consider the possibility that there might come a time when Cockpit would go HTTP 2.0-only, for example. That *would* mean a backwards-incompatible break with any browser that only supported HTTP 1.1 (for example).
Or consider a day in the future where JavaScript is no longer the gold standard in browser scripting and you perform a major rewrite.
I will grant you that these are exceptional circumstances... but not impossible ones (and I'm sure there are others not immediately coming to mind). Version numbers *do* provide a simple, programmatic way of indicating to other software that they may need to change to adapt to the new thing (without the maintainer of that software needing to actively be monitoring release announcements of Cockpit).
- Various parts of Cockpit can have different version numbers and work together. Just like parts of GNOME, or parts of Fedora (think modularity cough) have different version numbers.
Sure, but the overall project should have a version number that is representative of the whole system. With semantic versioning, you can actually use this as a shorthand to express which portions of the project are stable vs. in-development or experimental, simply by setting the Major version to 0.
So you might have Cockpit 1.2.0 that contains: cockpit-bridge = 1.2.0 cockpit-selinux= 0.56.0
They could be released as the 1.2.0 set but a conservative deployment could easily have tools that would skip installing 0.x portions of it.
- Cockpit has stable releases weekly. Not all users are forced to cycle through each one ... but this dilutes semantic versioning advantages significantly.
I do understand and respect the traditional "1.0" approach to software, but it's hard to make it work or apply in this case.
I'm not sure in what way it dilutes the semantic versioning at all. I think you skipped to a conclusion without presenting the evidence there.
As I mentioned above, if we version components independently, we can use semver to indicate stability. For the stable components, we increment the Minor release each week until we hit a case where something that was deprecated is removed, at which point we bump the major number for that component and the project as a whole and continue.
The way I see it working is that the individual components would see their own updates following semver and we would just use the highest-versioned of any of them as the overall project version (since that would guarantee that compatibility changes were propagated).
I understand where you're coming from on this. However, we will pay a price in advocacy/adoption terms if we do something unexpected with version numbers. It means that we spend time explaining our version numbers to people instead of explaining Cockpit.
The idea is not to explain version numbers at all. But rather "just use Cockpit". Cockpit version numbers are a diagnostic tool for when things don't behave as expected.
Forgive my bluntness, but that's naive. It works *kind of* for Firefox because the majority of users don't have specific feature requests; they just want to browse cat videos. However, for the set of users for which specific features matter (usually either extension writers or integration engineers for major sites like Netflix), this versioning scheme *is* problematic because they don't have any inherent clues when their stuff is going to stop working and their users will be upset. They are forced to either use humans to monitor the project changes (which is costly) or take their chances and try to fix things fast when they break (which has problems with user perception and also means their sustaining engineers are overworked and stressed).
Cockpit is very specifically addressing a different audience than Firefox: it's addressing the administrator of a complex system. This is a class of user that *does* have specific feature needs and *will* notice when things stop working (and will be very noisy about it).
(As an aside, it's also a class of people that are largely in opposition to the idea of constant new features and prefer LTS support for existing features as well, but let's talk about that in a different thread.)
In fact we've added some finishing touches on the diagnostic aspects of version numbers here:
And we'll probably put a bit of effort into the about dialog to show the various versions of the parts in play when it comes to diagnosing an issue.
Lastly we'll better document what's "stable" and what's "internal" before making this move.
This discussion has resulted in some good checks and forethought, but all in all, even after taking the discussion into account, the significant contributors to Cockpit have been in support of simply dropping the '0.x'.
I'm a little surprised that the conversation has focused so heavily on the Firefox and Chrome decision to go to rapid major versions rather than picking systemd which is a much closer analog to Cockpit; it's system software whose feature set is highly relevant to administrators. I don't have any information to share specifically right now, but I'd suggest that it might be useful to do at least a straw poll of real users and get their opinion on whether that versioning scheme works for them, irritates them or is irrelevant to them. That would be a much better guidepost for Cockpit I think than looking at the common-user case of the browsers.