|
From: Szakacsits S. <sz...@si...> - 2003-02-20 06:59:23
|
On Wed, 19 Feb 2003, Szakacsits Szabolcs wrote: > On Wed, 19 Feb 2003, Anton Altaparmakov wrote: > > On Wed, 19 Feb 2003, Szakacsits Szabolcs wrote: > > > How the new development tree should be "numbered"? The kernel style > > > odd/even minor version won't work (the release is 1.7.x). The x.y.99 > > > is not talkative and more importantly not scary (more write to NTFS is > > > coming). An also widely used versioning is marking the development > > > branch as -dev or -devel, so e.g. 1.8-devel could be used and the next > > > release would be 1.8.0 or 1.9.0, etc. > > > > I don't think we need a development branch. The snapshots should be just > > fine as far as developmental releases go and as far as BK is concerned > > people interested in the stable releases can download the correct TAGged > > version while people wanting the latest and greatest just download the > > current version. > > Ok, bad wording. We need a new product *version*. So just changing > 1.7.1 in the top configure.in. The current development > 1.7.1-200302191139 tar.bz snaposhots or 1.7.1 development BK pulls are > 1) confusing > 2) ends up reporting issues in stable version 1.7.1 however that's not > the case due to lack of proper versioning. Anton, I'm sorry I couldn't convince you. I try to explain more affable why it's bad when both the release and the new development version is called 1.7.1. The software has a life cycle like, simplifed a lot, development, release, maintaince. It doesn't stop when you think above somebody get's whatever fits her/him. If the software was found to be working, it may be distributed on the web, CD, file shares, etc by others. And it *is* distributed, it's open source, freely distributable. Now if one might find a problem, he will report it's the stable 1.7.1 and the developer (in case of ntfsresize probably me) starts ponder how the hell things could go so bad. After reverse engineering our own binary it could turn out somebody did a 'bk pull' and made a binary using the unchanged release version 1.7.1, what's also used for the new series development. During the same time rumours can spread, stable 1.7.1 eats your NTFS filesystem, people will not know/care you just didn't bumped up the version used for the next development cycle. If the version indicates a development release, e.g. 1.8-devel then people will be more careful and you can also say, "yes, the development version can destroy your data" or "please try the latest development or the last release" or "here is the fix for your problem", etc. Adequate software versioning is crucial, among others, for support, maintaince and not to undermine the reputation of the software quality. This is especially true when there are factors that the software can potentially destroy all user data and functionality is based on reverse engineered information. I'm talking about only this change, diff -u -r1.4 configure.in --- configure.in 13 Feb 2003 14:37:47 -0000 1.4 +++ configure.in 20 Feb 2003 07:51:52 -0000 @@ -12,7 +12,7 @@ AC_CANONICAL_SYSTEM -AM_INIT_AUTOMAKE(ntfsprogs,1.7.1) +AM_INIT_AUTOMAKE(ntfsprogs,1.8-devel) AM_MAINTAINER_MODE I hope I could clarify the issue a bit better this time. Szaka |
