2015-10-08 5:01 GMT-07:00 Nigel Magnay <nigel.mag...@gmail.com>: > >> 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? >
Users are trained to expect that v(x) -> v(x+1) is a big change. Often as a result of that, a major upgrade is incompatible, but it's not necessarily so. Eclipse, Bamboo, and Windows all version in this way. Major number incrment is used to signal feature changes, not necessarily compatibility changes. And Jenkins 2.0 is a big change for users --- you suddenly get a whole lot of new things you haven't used before, and it encourages & promotes different ways of using it. I think it's well qualified to call it 2.0, and I don't think it's trying to untrain the general expectation. And as Andrew is suggesting, let's then start collecting ideas for more developer-focused 3.0, which will likely take a longer time frame. -- Kohsuke Kawaguchi -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4znBhrCUhMVYrQdeMjqmS64qneZqdejZ513U4z6CkkHdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
