> 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? 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' ? 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 -- 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.
