future wpa_s/hostapd release plans

[Johannes Berg]

On Sat, 2011-09-10 at 23:32 +0300, Jouni Malinen wrote:
> On Thu, Sep 01, 2011 at 03:10:27PM +0200, Johannes Berg wrote:
> > Oh, and because this is a change, Jouni proposed calling the first one
> > that will come out of this "1.0" (first release 1.0.0), followed by
> > "1.1". (or did you mean 1.0 being the first release, followed by 2.0,
> > and fixes as 1.1, 1.2, ...?)
> 
> I think we could as well drop the extra value.. We've survived almost
> ten years without changing the "0." prefix in the version number, so
> clearly there has not been much need for it. In other words, we could
> fork hostap-1.git and release 1.0, 1.1, and so on from there and the
> next fork would be hostap-2.git with 2.0, 2.1, ...
> 
> And just to be clear on what the version numbers mean here, the 1.0
> version would actually map to the first stable release in the past
> (e.g., 0.7.3 in the case of 0.7.x branch). In other words, the
> development release concepts goes away (or well, the possible 1.0-rc1
> style releases could obviously be similar, but still, x.0 is the first
> "stable release").

That makes sense. -rc1 is certainly more intuitive than 0.7.1 :-)


> > Secondly, we don't have a fully functional test bed, so when/how do we
> > call what branched as 1.0 actually release-worthy? Jouni -- what's your
> > process there? Just "generally I'm happy"?
> 
> This has been pretty informal in the past, but things have been calming
> down in the stable branch for longer time before making the first stable
> release. I have usually tried to verify basic functionality for both AP
> (hostapd) and station (wpa_supplicant) functionality, but there has not
> really been extensive testing just for the purpose of being able to make
> a new release. I've also tried to run the source code through couple of
> static analysis tools before each release and address whatever issues
> show up. I should be able to do that with 1.0, too, once we get closer
> to the release time.
> 
> I have wanted to build an automated test setup for a long time, but
> haven't really ever found enough time to complete that.. In practice,
> there are number of projects that track hostap.git changes and run
> automated tests, so some testing gets done there. However, the separate
> release branch may actually get quite a bit less testing "by default"
> unless someone changes from tracking hostap.git to that branch.

Do you know who tracks hostap.git, and why? It would be interesting to
see if those projects would be interested in tracking hostap-N.git
instead or in addition. So far, I haven't seen anybody speak up here on
the list :-)

> For this particular 1.0 case, it would be nice to run through some P2P
> certification tests taken into account that P2P support is one of the
> largest changes between 0.7 and 1.0. In theory, I have a fully automated
> test setup for it, but it is not dedicated for this purpose, so I might
> as well call it manual.

That would be interesting, but I'm not sure I'd expect it to happen
before 1.0 is actually branched off. It could be part of the release
criteria for 1.0 in this case, but even there I'm not sure. I think we
might rather release 1.0 with P2P, get people started using that, and
then release 1.1 after fixing some bugs in certification? I don't really
know which approach is better though.

> I'm not sure whether I would actually be using the stable branch for
> projects that I'm involved with since I've already gotten very used to
> picking builds directly from hostap.git.. As such, the question of
> testing the release branch may fall more for those who are planning on
> using it until we have a fully automated testbed in place.

That's perfectly valid. I think at minimum we'd run some (more) P2P
tests and we do have basic functionality tests for our devices using
wpa_supplicant that we should be able to plug in a new version to.

johannems