Nmap Development mailing list archives

Re: Nmap release schedule/plan/rationale


From: Fyodor <fyodor () insecure org>
Date: Wed, 22 Sep 2010 18:29:53 -0700

On Wed, Sep 22, 2010 at 12:23:57PM -0500, Daniel Miller wrote:
Hey list,

A big thanks to everyone who contributes and produces Nmap, my favorite 
security tool by far.

I'm glad you find Nmap useful!

My question: Does the Nmap project have a release plan, or a rationale 
for how to decide when to make a release?

Each release is handled on a case by case basis.  Many factors are
involved, including:

o If there are known bugs/problems in current releases, we expedite a
  new release based on how severe those problems are.

o As new features pile up in SVN, the urge gets stronger and stronger
  to put them out to a greater userbase with a new release.

o If there are a lot of new features or other big changes, we
  generally do dev releases and give them a period to stabilize before
  making a stable release.

o It depends on how busy we are.  Like during SoC, we're doing so much
  code writing and review that it is hard to find time to also build and
  announce a new release.

o It depends on what is coming soon.  If there is a big change coming
  up, we might want to get in a release first to avoid waiting for the
  change to be fully integrated, tested, and stabilized.  In other
  cases, we might delay a release until we can get a certain desired
  change in.

o It depends on what else we're working on.  Creating a release takes
  time which could otherwise be used for development, documentation,
  etc.  Doing a release every other month takes less (total) time than
  monthly releases, in general.

That may be a longer answer than you were looking for, but there it is
:).  We don't have any release dates planned right now, but my guess
is that we'll have a dev release within a month and I'm pretty sure
we'll have another stable release this year too (based on that new dev
release).

I use the SVN repository for my own testing, but for work I have to
use stable releases. Reading the changelog and this list makes me
excited to use new features in my daily work, so I'd probably want
more releases than is probably prudent.

Maybe you can get this policy changed?  If we were talking about a web
or email or DNS server, I can understand a big risk aversion to using
an SVN snapshot or dev release.  But what is the big risk of using an
SVN version of Nmap, or at least a dev release?

In a very related note, I don't believe the project has a process for 
issuing "bugfix" releases, which I think could be helpful. Oftentimes 
bug reports are given and answered with, "That was fixed in rXXXXX." I'm 
not as familiar with subversion, but I know other VCSs like git have the 
ability to "cherry-pick" commits from other branches, which can be used 
to apply bugfixes to a stable branch for bugfix-only releases, without 
hindering new feature development. Has there been any discussion about a 
similar workflow for the Nmap project?

This is how our current Nmap 5.21 release was made.  Our announcement
tweet for it was:

"Nmap 5.21 released with zero exciting new features! But this
 bugfix-only release should be extra stable."

But a bug fix has to be pretty important for us to backport it into a
new stable release.  The branch in our SVN repository for this stable
series is /nmap-exp/stable-5.2.

In general, we recommend people run dev releases or even SVN.  Maybe
you can get your work policy changed?  Having people use SVN (or at
least the most recent dev release) helps the project too--it brings
more testing to the new code so that it stabilizes faster.  It also
reduces the number of bug reports we receive for issues we've already
fixed in newer releases or in svn.

Cheers,
Fyodor
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: