in general I agree with your (I'd like to see changes in backend happen as
well), but I'm not sure about this one - you don't expect any API changes or
you propose to do backward incompatible changes in a minor version change? If
the former, IMHO it doesn't need to be bind to 2.0, just form group of
interested devs and make the change, if later it seems to me quite unfortunate
to do any incompatibility changes during minor version bump. IMHO lots of
people expect, if not state clearly otherwise, that any backward incompatible
changes happen only during major version bump.
With 2.0 bump discussion, IMHO it would be useful if we define what major
version bump exactly means for Jenkins (i.e. still very limited backward
incompatible changes; only some API changes - only plugin maintainers should
take care; backward incompatible changes can happen - every admin should take
care and look if some config migration is needed; etc) and also how often we
expect major version changes. If cca once a year (or e.g. once some major
feature is developed and tested), IMHO it's fine to wait with it for 3.0, if
we stick with 2.0 for another 10 years, than makes sense for me to postpone
2.0 and implement more changes.
We have differing visions of what "Jenkins 2.0" would actually mean, and those visions are to a certain extent mutually incompatible - getting 2.0 out in the timeframe Kohsuke has proposed wouldn't be possible if that requires not just the user experience work he has mentioned but also storage changes, a jenkins configuration API, etc...
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' ?
Also - why can't 1.xxx continue in parallel to 2.x ?
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.
* 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.
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.
>
> 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?
Fair enough.
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2dMrOqZYs8m15sH5SJ2A%2BsB6nbQi%3DwwEmHqw0wWXKKgg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdObw2OXXH2wJ5sXN3%3DwG7e1TO6gcjzD_n97bL1qe-Cjeag%40mail.gmail.com.
That sounds reasonable to me. Given the likelihood that I misjudged how long the storage change would take, it's very plausible that any of the larger architectural improvements would take long enough to wait for late 2016.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5jhAKuxJu%3Dz2tt2-xACkR98rvmZUsT2D8KNw8h6ecbaw%40mail.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?
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
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.
--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0W%2BTZOvLgmrCYq%2B7RR7u1a%2BFvWmSHMO_7itPjfvDamaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.