kismet and svn builds?

[Chris Ricker]

On Thu, 19 May 2005, Tom 'spot' Callaway wrote:

> On Thu, 2005-05-19 at 12:09 -0400, Chris Ricker wrote:
> 
> > 3. kismet support for ipw2200 cards requires a build from the kismet 
> >    development svn tree. How does one package a cvs / svn / etc. checkout 
> >    for FE? Or is the answer just "don't do that" :-)
> 
> We're still trying to figure that out.
> 
> Right now, I think this is the wording I've got so far. Please point out
> flaws in this.

<snip>

Thanks, that helped

To complicate things, kismet started out with the more-or-less traditional 
major #.minor #.tiny # versioning scheme. After it hit 3.1.0, the author 
switched to a year-month-release# scheme (which, just to be 
extra-confusing, he describes in the documentation as a 
month-year-release# scheme ;-). So, releases now look like

2005-01-R1
2005-04-R1

Based on that, I thought the %{version} for the latest stable release 
should be 0.2005.04.1 (0 just so I don't need an Epoch if the naming 
scheme ever goes back)

So, I'd do something like

kismet-0.2005.04.1-1

for the initial package of the release code, then

kismet-0.2005.04.1-2.1.20050518svn
kismet-0.2005.04.1-2.2.20050519svn

for subsequent builds from the development checkout.

One thing that's not clear: when would I ever change the first field of 
%{release} once going to the post-release SVN checkout format? Meaning, 
after I've done:

kismet-0.2005.04.1-2.1.20050518svn
kismet-0.2005.04.1-2.2.20050519svn

when would I ever do

kismet-0.2005.04.1-3.whatever

? It kinda seems like that first field in %{release} is superfluous?

later,
chris