Closed jkubrynski closed 4 years ago
Thanks for the thought. We needed something that was disconnected from individual project versions. We followed the precedent set by spring data. We're 5 years in. We don't plan on changing
Just for your information. I've started the survey on Twitter about your approach to versioning: https://twitter.com/jkubrynski/status/1113804447002398721
80% of the people voting don't like it. Do you want to totally ignore it? Just because you do something for 5 years doesn't mean you're right.
We're following a Spring portfolio standard. You'd have to convince all of the spring projects that do this to change (reactor, data, stream and more).
I don't have to do anything :) I'm just sharing my best knowledge with you. Something I know from the talks with many developers backed with a simple twitter pool to have numbers not just words. If you want to ignore the voice of the community - totally fine. I used to it :)
Currently, all Spring Cloud release trains are named in alphabetic order using London Tube Stations. It's not something that developers are used to. Even Android which uses alphabetically ordered names (Nougat, Oreo, Pie) is simultaneously using normal versions (7.0, 8.0, 9.0) to make it easier to remember. Tracking Spring Cloud releases is hard for someone not working with those versions every day (as people in Pivotal do).
I totally agree that release trains need different release pace, but there are better options as for example suggested here: https://twitter.com/bartekpiech/status/1113809870191497219
Calendar versioning (2018.3, 2019.1, 2019.2) is already used by JetBrains and it's much easier to remember.
Please rethink the approach to versioning releases to make it usable for regular developers.