|
From: Szakacsits S. <sz...@si...> - 2003-02-21 12:53:11
|
On Fri, 21 Feb 2003, Anton Altaparmakov wrote: > > Sounds to me like you actually want a separate development tree which will > contain code which is going to destroy people if they use it. I have No. I have extensive test automation and I do test/verify what I submit. But nobody is perfect and nobody can test what she/he doesn't know about, especially in the rapidly changing software environments and reverse engineering involved. > always aimed to keep my code stable at all times and never have code that > would be destructive (apart from bugs I haven't found obviously). I admit > there have been short periods where I have said "don't use this it is > destructive" but I have always tried to fix them asap... I am going to My experience is that you occasionally make a wrong fix (I told, nobody is perfect) and making things worse sometimes you even don't communicate the broken fix back for confirmation I reported before making and announcing the new release/snapshots. I also noticed, you don't always test/verify your code. Don't think I mean you have to. What I use from libntfs I review, test, etc. The quality and coding style of the ntfs library is also error-prone. Ultra-long functions, copy-pastes all over, confusing/misnomer naming, inconsistent API, etc. These are the disturbing facts why I'd prefer a clearly indicated development "branch", not because I'm preparing to destroy user's data. > The version of the development tree will be "ntfsprogs 1.x+1.y-devel" for > a stable version of "ntfsprogs 1.x.y". That looks ok, if you mean 1.8.0-devel (your notation implies 1.8.1). > Then the development repository will be for all experimental code. The > only thing to note here is that you will have to mark you patches very > clearly as to which repository they should go to. And remember that if I > apply something to the stable tree I can use BK to get the same stuff > merged into the devel tree but not vice versa, i.e. patches to the devel > tree will never make it to the stable tree, except when the devel tree is > turned into the stable tree at some point in time for the next big > release. Sounds good. > As far as versioning is concerned I use major_hi.major_lo.minor as > version numbers, i.e. 1.7.1 -> 1.7.2 is minor updates but 1.7.x to 1.8.0 > is major updates and after 1.9 will come 2.0 as natural occurence. If > something really major happens before 1.9.x is out we may jump to 2.0 > already (note really major means a full rewrite of the library or things > like that). Thanks for explaining. I hope I wasn't offending, it wasn't my intention. Szaka |
