|
From: Szakacsits S. <sz...@si...> - 2003-02-21 10:18:31
|
On Thu, 20 Feb 2003, Anton Altaparmakov wrote: > > The version in bitkeeper is now changed to 1.7.2-WIP. [...] > * We are now on 1.7.2-WIP and want to make a 1.7.2 release. [...] > Happy now? Don't care about my happiness, care about users' one ;) In general that makes happy developers as well. But I can make my comments, if interested. (Free) software project management guidelines recommend, among others, internal consistency and clearly indicating the differences between development and release versions in the "version numbers". To avoid confusion, also documenting how the versioning is done. Apparently you're using the GNU version numbering (major.minor.patch) but maybe not, it's not documented. If yes, then the above 1.7.1. -> 1.7.2 change indicates a "fixing bugs" release. Unfortunately my forthcoming, potentially very dangerous, ntfsresize with cluster relocations new code and new NTFS tool[s] don't fit this. About the "WIP" extension in the development(?) tree. I'm afraid it's uncommon and cryptic for the majority of users. I guess you made this choise based on e2fsprogs versioning. However there are several differences between ntfsprogs and e2fsprogs from users point of view: - ext[23] is fully documented/known, NTFS is not. - ext[23] has a long time well established solidness and reliability, NTFS support on Linux is just completely the opposite. - ext[23] users, in general, much more technical, probably being able to figure out at first sight what WIP means, while most NTFS users are must cope with the countless new terms when starting to use Linux. Considering the aboves and unless you plan a "bug fix" patch level release, of course providing you're using the GNU version numbering, I would recommend the usage of 1.8-DEVELOPMENT or 1.8.0-DEVELOPMENT, clearly indicating the current ntfsprogs state in development. Sorry to be apparently picky, if the project would be a "Hello World!" caliber, not about potentially totally destroying Linux newcomers' old data, I wouldn't bother mentioning these. Szaka |
