> > > Ok, I'll bite. > > There are a number of conflicting things we need to balance. > > * There are some bigger UI/UX refreshes that we want to get out to > users. A long standing complaint is that the Jenkins UI/UX is dated. > Moving to a 2.0 label corresponding to the visible UI changes helps > advertise the fact that the Jenkins UI/UX is being updated
* It is hard enough getting users to upgrade to LTS lines, when they > see a 2.0, there will be a bigger fear of upgrade breakages... in a > sense that is why we have not done a 2.0 yet... I believe that to be a > mistake. I think a better thing to do is to bump the major version > more regularly... so I would see 2.0 being the 2016 release, 3.0 being > the 2017 release, etc (though KK may feel differently). If users build > up the expectation that "yes it's a major bump, but normally they > don't break too much in a major bump... it's more like jumping 4 or 5 > LTSes" then we can keep the users with us. > I don't follow why that's a bad thing though. "Users" are trained - by basically the entire software industry and for better or worse - to feel that a 1.x -> 1.y upgrade they can consider 'easy', but a 1.x to a 2.0 should be considered 'harder', and at least to read the changelog before performing an upgrade. We even codified it as 'semantic versioning'. If I understand your goal, it's to try to un-train that behaviour, so somehow users will learn that - for Jenkins - an v(x) -> v(x+1) *isn't* a 'hard' change. The problem I have with that is a) it's counter to expectations, and b) what do you do if you *do* want to signal a major bump with compatibility consequences? * We all have our pet crappy APIs that we want to kill off... the > allure of a major version bump is a siren luring us towards breaking > more stuff > > So I see Jenkins 2.0 more as a new version numbering scheme... > > We could call it Jenkins 2016 rather than 2.0... but that would set an > expectation that in 2017 we would roll out a 2017... given how hard we > find sticking to the LTS schedule I'd rather go with a major version > bump every 12-18 months. > > Then we can set out a deprecation policy, say that we remove APIs that > have been deprecated for 2 or more major version numbers... perhaps we > can use some static analysis or other tooling to alert you if your > plugins are using deprecated APIs. > Fine, but as a plugin writer it feels like death by a thousand tiny cuts. I'd rather a direct train from A to B, rather than stopping at all the minor stations in-between. Part of the reason I think there is excitement about a '2.0 line' *is* the ability to break long-standing compatibility - to finally address some of the stuff that's perennially kicked into the long grass. I think there's a tension between a commercial desire to maintain high levels of backwards compatibility, and a developer desire to get on and fix stuff. Endlessly updating plugins as Jenkins painfully modernises inch-by-inch isn't much fun. > In my vision, thus, Jenkins 2.0 is about sending a message that the > project is changing how it views compatability with the past... it's > still important so we are not removing dead APIs yet, but we have to > start putting lines in the sand so that we can remove dead APIs in the > future. > > I'd rather 2.0 *was* the one where the dead APIs were removed. That matches my expectation of what a 'big number change' means. > > > > If the changes are so watered down - (no breaking changes, no database, > no > > jdk upgrade) I don't really see the point of incrementing the big number. > > Isn't it that just 'business as usual' ? > > It's about setting expectations for subsequent versions. > > > > > > I think a 2.0 should include all of the things you're identifying. If > lots > > of things are constantly put off for 'we'll do that, but in v.Next as > it's a > > breaking change' surely it makes sense to actually do them, take the hit > in > > one go? > > > > Also - why can't 1.xxx continue in parallel to 2.x ? That gives it a > longer > > time to cook, provide upgrade paths from 1.x. e.g: plugins could declare > > themselves 'ready for 1->2 upgrade', and the installation could inform > the > > user 'you're good to go'. This is a fairly well-used pattern on other > > projects > > Python 3 anyone? > Linux 2.4 / 2.6? Ubuntu? We already manage an LTS line. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83REgFE2qjj_RNs9k6-6K4uxTO-Wos8HeG5srvtbf8ndwQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
