+1 for breaking activities into threads, +1 to let Andrew lead the database backend activity; +100500 for moving all compat changes to the third track. Had the same proposal in the Jenkins 2.0 thread, but it has been lost in other comments. Compat track is a painful stuff, but I think that Jenkins needs it to avoid the architectural paralysis.
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' ? > No reason from the technical side. BTW it should be a message to the community. Also - why can't 1.xxx continue in parallel to 2.x ? If we introduce breaking changes, we will have to do it. If the scope of changes is limited, it is not a big deal. For a real "Jenkins 2.0" we need to have an internal fork for at least 6 month in order to let Jenkins stabilize a bit. I always vote for long-term release lines (1 year or above), which would allow large-scale installations to avoid making de-facto custom forks. This upgrade is an opportunity to change the approaches. Best regards, Oleg четверг, 8 октября 2015 г., 13:45:43 UTC+3 пользователь nigelm написал: > > > 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/c7b88660-9cd0-460b-a0e4-4cb512148711%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
