> 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. >
Yeahhhh no jenkins.cd !!!!! > 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... > And couldn’t we start to provide new/distinct APIs (for storage, ….) and we start to slowly use them but we don’t enforce plugins to use them ? > 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/424DAB5D-80FC-4012-8A17-55D8363BD7B1%40gmail.com. For more options, visit https://groups.google.com/d/optout.
