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: 1. 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.. 2. 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. 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. 3. 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. 4. 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 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. In fact we've added some finishing touches on the diagnostic aspects of version numbers here: 1. https://github.com/cockpit-project/cockpit/pull/4964 2. 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. 3. 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'. Stef
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
