Jenkins 2.0 has been released! Please give it a try and provide your feedback.
Here is a rough timeline of the release/launch:
We'd like to validate that what we are proposing here actually solves people's problems. That will help us modify and prioritize the plan.
To collect those feedbacks in a manageable way, we have prepared a number of "2.0 planning tickets", divided under several themes called "epic tickets" in JIRA. This page and its children walk you through the main parts of those epics and details, and takes you to the actual tickets.
For historical archiving, here are earlier conversations that were done as mega threads:
As a community member and a future user, we'd like YOU to COMMENT and VOTE on those tickets. If you have more serious thoughts that do not fit in a comment or a vote, please feel free to post emails to the dev list or file additional tickets and link to the 2.0 planning tickets and/or epic tickets. The only thing we are trying to avoid is having more of the mega threads that nobody can keep up with.
Overall pitch and its slide version.
Introduce a new subsystem in Jenkins that moves job configuration in SCM and makes job creation automatic.
A revamped new-user experience would help the numerous people who set up Jenkins for the first time. An important part is guiding new users through the installation of important plugins.
A more powerful plugin manager. A revamped UI for configuring jobs, views, build agents, etc. An easier to use "New Item/View/Agent" dialog.
A new web site, which could include curated documentation, more visible events and blog, and/or a usable plugin index.
Servlet 3.1 enables alternatives to polling Jenkins for changes every ten or so seconds through use of Web Sockets. This will require use of a fairly recent servlet container (Jetty 9.1+, Tomcat 8).
Based on this discussion, the following proposals are currently considered for a release later than 2.0.
It's cumbersome to set up Jenkins in config management tools such as Chef. A proper API for configuring Jenkins would make this easier. The CLI isn't enough.
Proposal on the dev list
Being considered for a later 2.x release
Move parts of file storage into a database and/or make it pluggable.
Deprecated methods remain around forever, polluting code and documentation and making new development more cumbersome.
Enable more flexible upgrades of Groovy.
Better isolation of the libraries core uses from plugins, so that "not breaking plugins" doesn't have to be a concern for use of libraries that should be internal to core, as it is today.