Am Samstag, 9. April 2016, 18:33:33 CEST schrieb David Faure: > On Saturday 09 April 2016 17:04:06 Friedrich W. H. Kossebau wrote: > > Though perhaps the versions should be added to bugs.kde.org on time or > > even > > before bumping the version number in the sources. Because developers who > > run from latest git master and find bugs would rely on the version number > > they see in the sources. So when saying "bug in 5.55.0" it should be > > clear to which history span of the sources this refers to. Especially as > > developers using latest git are possibly of the more active bug > > reporters? > > They are, but I disagree with creating versions before they are released. > If you find a bug in git from after 5.54 and before 5.55, then you shouldn't > report the bug as a 5.55 bug. Because there might be a bugfix coming before > 5.55 is out, and your bug report would really confuse the developers.
True, using release version numbers for random development branch state (considering snapshots from master branch as such) does not really help. Versions ideally refer to a given state of the source code. So how to cover the case for developers trying to note a regression/new bug in the development branch? IIRC elsewhere I have seen people using a version called "git" in issue trackers, which would be used by developers for random snaphots and have them state the git commit id explicitely in the bug report. But that makes it hard to track regressions/new bugs between 2 versions. So what about some "5.xx.0-pre" version, set once the "5.(xx-1).0" is branched? That would allow to collect regressions/new bugs in the development phase separately, without mixing them into bugs for the last released version. Cheers Friedrich _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
