I feel the same way as Andrew, I remember when we where talking about things we would have loved to do but where afraid to do because of backward compatibility - the answer coming up that time always was: we can do this with v2.0, but not now yet. Although I really think the direction we are going now is the right one, I sometimes would wish for more courage - I’m sure the v2.0 label will be accepted by our users to take some extra effort when upgrading. /Domi
> On 07 Oct 2015, at 21:57, Andrew Bayer <[email protected]> wrote: > > So looking back over the thread - my concerns have pretty much all been about > missed opportunities to address stability and performance issues that may > require more work in core than we normally do in a release (not necessarily > compatibility-breaking ones). In the 7 or so years I've been involved with > the project, there've been many times when we've said "Well, maybe we'll do > that in Jenkins 2.0" so seeing 2.0 coming without the opportunity to make > those sorts of changes takes a bit to get used to. =) > > But! The branding/messaging stuff has value - well, most of it - I'll fight > to the death against jenkins.cd <http://jenkins.cd/>. =) I know I've been a > really big fan of curated plugin packs or something along those lines to help > users get up and running, and the UI framework definitely needs a complete > refresh. Yeah, my dreams of Jenkins 2.0 going out the door with a drastically > revamped storage backend and better support for analytics aren't going to > happen - but that doesn't mean they *won't* happen in 2.20, 2.30, etc. The > plugin compatibility testing is going to be something hugely useful for > making significant changes to the core in the future - if we can get a good > regression testing framework that covers a broad array of plugin use cases, > we can be more liberal in changing core in the future. > > 2.0 isn't going to be what I've always thought 2.0 would be. It's not going > to fit the semantic versioning definition of a major version change. But 2.0 > is still a good way to label the kind of UX/on boarding changes that are so > central to what Kohsuke's proposing. Let's take this as an opportunity to > figure out how to do planning for significant changes and new features in > core that take time to deliver - this time, it's user experience, look and > feel, and out of the box that are the main focus, but perhaps when 2.0 is out > the door, we will focus another couple months of work on storage and memory > utilization, or plugin cleanup, or... > > A. > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZaTbv6LQqPvDV56tWSxbX1Au%3DBC2uBcAwc0cxqL17OpA%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZaTbv6LQqPvDV56tWSxbX1Au%3DBC2uBcAwc0cxqL17OpA%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/89E9EE3F-FD8E-44FD-9BF5-AF5FB05770CA%40fortysix.ch. For more options, visit https://groups.google.com/d/optout.
