Future hostapd and wpa_supplicant releases

[Jouni Malinen]

Based on the discussions at the Linux wireless summit in Barcelona, it
looks like there is somewhat limited interest in maintaining (or at
least volunteering to maintain) long term stable release branches, but
there would be use for more frequent tagged releases. This will change
the release process for 2.0 and newer releases of hostapd and
wpa_supplicant.

The current plan is to make more frequent (maybe every couple of months)
releases (2.0, 2.1, ..) directly from the master branch of hostap.git
instead of forking a release repository or branch prior to the release.
There would not be a new release branch (or repository) by default for
stable releases, but I may end up creating a new branch whenever there
are significant bug fixes after a release (i.e., to git cherry-pick bug
fixes from the master branch on top of the latest release) so that such
bug fixes are conveniently available for any release purposes (e.g.,
distro packages). If someone wants to maintain a longer term stable
release branch similarly to the past 0.7.x and 1.x uses, that is
obviously still possible, but that would be fully independent of the new
releases from the hostap.git master branch.

To reduce risk of last minutes regressions, I'm planning of postponing
commits to the master branch for new functionality (i.e., take bug fixes
or some obviously correct small changes) during the couple of weeks
prior to a new release. This is unlikely to be a strict rule, i.e.,
there may be exceptions, but anyway, be prepared to not getting new
functionality into a release late in the cycle.

I'll start a new branch ("devel") in hostap.git for postponed commits
and will then merge those into the master branch once the next release
has been made. In addition, some more experimental commits may end up
spending time in the devel branch even a longer time if they are not yet
ready for the master branch, but could be helpful to make available for
others. It should be noted that the devel branch will be frequently
rebased on top of the master branch (i.e., only the master branch has
immutable history).

Please let me know if you have any concerns with the new release process
or if you have ideas that could improve this.

I'm thinking of releasing 2.0 in a week or two, so the master branch is
going to have tighter control until that release. Any testing of the
current master snapshot would be welcome to get any potentially
remaining issues resolved prior to the next release.

-- 
Jouni Malinen                                            PGP id EFC895FA