On 8 October 2015 at 11:45, Nigel Magnay <[email protected]> wrote:
>
>> 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...
>
>
>
> I don't understand the rush to label something as 2.0 ? Why not extend the
> timeframe?

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?

>
>
>
>
>
>
>
>
>
> --
> 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/CAPYP83QixUeFYp5UU1gekE1KwadQVV-cA9r4fjQg-1oQHy1eZQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CA%2BnPnMzpr-K0jhkgF9K6fwk469W4ebkDMr%2BS6TuhMw1W9MXSOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to