Packaging Argus 3.0 for Debian

[Andrew Pollock]

On Wed, Apr 12, 2006 at 09:21:57AM -0400, Carter Bullard wrote:
> Hey Andrew,
>    Long time no read, hope all is doing very well for you!!!!!!

Slow and steady.
 
>    This is a major version number change as its a completely
> different output format.  The argus and its clients will be
> backward compatible.  Backward compatible in that they can
> use existing configuration files and the clients will be able to read
> previous versions data, but,  2.x clients will be clueless as to how
> to read 3.x data.  Users will have to commit to a change if they
> use argus-3.0.  The feature set is not different, but there are a few
> new features that have crept in, so that's not 100% accurate.

Sure, that's fine. If Argus 3 couldn't grok Argus 2.0.6's data or config
files then we'd be in a bit of an upgrade mess.
 
>    With regard to options, we will have a lot of work just to realize
> whats different, as argus-3.0 was a clean slate implementation,
> but, again, lets say 80-90% right now is the same.  The output
> format for some programs will be noticeably different, maybe
> a column title is sightly different spelling, filter syntax is the same
> but maybe a keyword is slightly modified, that kind of thing.
> 
>    New features, for argus we'll be able to track IPv6 flows, there
> are 64-bit counter support, and we'll support native 64-bit
> machines, and we'll support MPLS labels in flows.
> 
>    For the clients, we'll have a new program, rasplit(), which
> resembles the unix split(1) program, and is used primarily as a
> record collector and to support sorting, etc...   The number one
> program for modifications is ratop(), which should be the data
> viewer of choice, or at least that is how I want to sell it.  Its still
> curses based, but it has a large number of changes to make it
> useful.
> 
>    So with all of that, lets just package it as argus-3.0.  The argus
> is ready for testing, and I'm working on the initial client test release
> now, but with the holiday coming up, I probably won't have it
> ready until after Easter.
> 
>     And last but not least, its your turn to tell us what would help
> you, especially with version numbering and installation
> guidelines, if we're not doing the right thing.

My only request is to keep the version numbers simple and sane. The "fixes"
suffix and the "rc" suffix made a bit of a mess of things, because
lexically, "fixes" precedes "rc", when this wasn't the case chronologically.

You could do "rc" again for release candidates, but I think you should stick
with a 3 part version numbering system for post 3.0 releases, so just use a
minor revision number instead of "fixes".

regards

Andrew