On 7 November 2011 02:34, Vincent PINON <vincent.pinon at st.com> wrote: > Alberto Villa wrote: >> On Monday 07 November 2011 00:45:10 jb wrote: >>> Great! At first I wanted to make it 0.8.2.1, but the changes will be more >>> important than first thought... ?with at least 6-7 severe bug fixes. That's >>> why I thought 0.8.4 would be more appropriate. >>> >>> Anyways, I don't really care about these version's number, so if you think >>> 0.8.2.1 is better it's ok for me, as long as I manage to fix these issues. >> Not important at all. And your opinion on 0.8.4 makes sense. ;) > To my opinion 0.8.2.1 would be more appropriate to state that 0.8.2 is > not perfectly stable, and needs an upgrade without additional features, > even if code changes are not so light... > If I wanted to select an "old-stable" release I would take this into > account. Usually incrementing he "second significant digit" implies new > features, don't you think ?
If I can add my 0.2... Changing the number of numbers in the release is a pain to handle in automated scripts for distrobution maintainers. Is Kdenlive ever going to get to a 1.0.0 release, or is the leading 0 going to stay like that forever? In my opinion, kdenlive could follow the kernel dev's example, and the version be bumped to 1.0.0. Then the second significant digit ( 1.x.0 ) can be used for extra feature releases, and last significant digit ( 1.0.x ) for bugfix releases. In this manner, scripts can automatically pick up when a new release is available, and the distro maintainer's job is a lot easier. As the number of numbers in the release does not change. -Evert-
