Packaging Argus 3.0 for Debian
andrew-argus at andrew.net.au
Sat Apr 29 13:06:18 EDT 2006
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
> 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".
More information about the argus