Task #2462
closedWrite release notes for version 0.3.0
Added by Alex Afanasyev almost 10 years ago. Updated almost 10 years ago.
100%
Files
integ201502022117.tar (77.5 KB) integ201502022117.tar | Junxiao Shi, 02/02/2015 08:29 PM |
Updated by Alex Afanasyev almost 10 years ago
From gerrit comments:
Davide:
I don't understand why 0.2.1 and not 0.3.0
There were quite a few major/breaking changes in this release (e.g. C++11 transition, API removals, ...)
Alex:
This is version management... This one suppose to be a "rolling" release that points a version before the release... I would agree that it make more sense to call it 0.3.0, as we didn't do (official) rolling releases before... We can discuss this on monday during the call
Davide:
I'm not sure what you mean by "rolling release"... 0.3.0_rc1 then? or _beta1 or _whatever1? even without the trailing digit if you think there will be only one.
Updated by Alex Afanasyev almost 10 years ago
During one of the calls we decided that we will do major releases when all the planned features are accomplished. In between major releases we will do time-based (e.g., every month or so) "rolling" minor releases.
This is why version 0.2.1 is assigned to the upcoming release. However, given that we just established versioning policy, we may consider to jump ahead and assign version 0.3.0 to this one and re-assign unfinished features to a future release.
Updated by Junxiao Shi almost 10 years ago
If we plan to do rolling releases from now on, I suggest abandoning semvar, and tag each release with date.
This practice is used in: ArchLinux, Ubuntu, Foursquare for Android, etc.
Updated by Davide Pesavento almost 10 years ago
Alex Afanasyev wrote:
During one of the calls we decided that we will do major releases when all the planned features are accomplished. In between major releases we will do time-based (e.g., every month or so) "rolling" minor releases.
I wasn't aware of this decision. In that case, I believe that using a time-based version number as suggested by Junxiao would be the best approach (e.g. <year>.<month>
).
Alternatively, use a hybrid scheme such as <major>.<month>.<patch>
, where <patch>
is intended for urgent bugfix-only releases, thus it's usually zero and can be omitted.
Updated by Alex Afanasyev almost 10 years ago
I would stick with just version numbers. I don't see how date-based versioning is superior to it. In Ubuntu case it is part of branding, I don't known about others.
Updated by Junxiao Shi almost 10 years ago
A date, when represented as yyyy.MM.dd
format, is a version number, although it doesn't conform to semvar.
Updated by Davide Pesavento almost 10 years ago
Alex Afanasyev wrote:
I would stick with just version numbers. I don't see how date-based versioning is superior to it. In Ubuntu case it is part of branding, I don't known about others.
It's more predictable and carries meaningful semantics. In the end they're just numbers :)
Updated by Alex Afanasyev almost 10 years ago
Just version number carries more semantics for me. It doesn't really matter when exactly code is released, what matters for me is functionality.
Updated by Junxiao Shi almost 10 years ago
It's harmful to release 0.3.0 now and rename planned 0.3.0 to 0.4.0, because previous promises about "X will be available in 0.3.0" will be void.
It's okay to release 0.3.0-beta1 now, and release 0.3.0 when promised features are completed.
Updated by Junxiao Shi almost 10 years ago
- Subject changed from Write release notes for version 0.2.1 to Write release notes for version 0.3.0
20150202 conference call decides to call this release as 0.3.0, and the release planned in Feb 20 as 0.3.1.
Updated by Junxiao Shi almost 10 years ago
- File integ201502022117.tar integ201502022117.tar added
upload integ results
Updated by Junxiao Shi almost 10 years ago
integ is still failing, but I ran the cases manually and they are passing.
I think the release is good to go.
Updated by Junxiao Shi almost 10 years ago
- Status changed from Code review to Closed