On Friday, October 9, 2015 at 9:14:47 PM UTC+3, Kohsuke Kawaguchi wrote: > > > 2015-10-08 5:01 GMT-07:00 Nigel Magnay <[email protected] <javascript:>> > : > >> >>> 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. > I was on jenkins 2.0 meeting that took half of it presenting workflow. What is the problem to use workflow in 1.xx? I don't see that workflow requires breaking something in core. UI change yes. DB change - yes.
> > 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. > Then people will wait for 3.0 as UI is not a blocker for current usage (of course everybody wants new UI, but it not a really usage blocker), while performance and features - yes :) > > > -- > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/11b017e4-7928-4d58-8009-92b45c50adda%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
