Fix 'release' target

fixed in r1460.

This is not "fixed" in the way the ticket description describes, just removed. I think this ticket should be open until a valid release target is added to the Makefile, or it is decided that a release target is not required.

but what is the point of having a release target in the makefile? no-one can use it, except for developers with svn write access, since it's supposed to tag a version in the repository. The version snapshots at http://snapshots.madwifi.org/madwifi-ng/ which kind of replace the need for releases, right?

The snapshots are snapshots, not releases. And you are correct that the release target is only for the developers to tag a final release, as that is what the general aim of all this recent development is striving to acheive!

Plus, if a release target is there, mrenzmann may be more likely to do a "make release" sometime in the not too distant future ; )

So is it true, that once this is make release is fixed, we can have a 0.9.0 version out ?

We're near the first release, it seems, but some things still need to get done. For example #565 is also open, and it's about an important issue (I agree with kelmo in that regard).

To stay ontopic: I think we need to tune the sources a bit in order to reflect which release is used. For example, this could be done by defining RELEASE_VERSION in release.h. And we shouldn't forget to "disable" the svnversion.h target for releases.

What other steps are needed for the release target? For now I have on my (yet unordered) list:

• tag a release in the repository
• add the new version to Trac's "version" list (so that tickets can be filed for the releases)
• create a tarball for the release
• put the release tarball to sf.net (which will be our primary release distribution site, I think)

Something's missing? Comments?

Mike, I think you have covered all the requirements. Thanks.

Kel.

After looking at sf.net's File Release System (FRS) I think that automating the "put release tarball to sf.net" step should be deferred for now. I've found two tools that allow non-browser access to the FRS: one is a QT GUI, one is a Java class. In other words: no ready-to-use command line tool, and I don't feel like writing one right now.

In addition we should add a Freshmeat announcement for every release.

Updated task-list now looks as follows:

1. Create "release" target, which tags a release in the repository, adds a new version to Trac's (ticket) version list and creates a tarball for the release.
2. Add a to-be-done-for-releases file to the repository as reminder for the person who makes a new release; this file would remind of creating the file release at sf.net and announcing the release on madwifi.org, the madwifi-users mailing list and freshmeat.net (including a quick'n'dirty guide)

Proposal for "release" target

Request for comments

The attached patch implements the needed "release" target, please review and give feedback.

It works like this: Joe Developer, who needs to have write access to the Subversion repository of our project, calls "make release" from the top-level directory of his working copy. make then calls a Bash-script (make-release.bash) which does the main work:

1. determining the desired type of release (I tried to make this as comfortable as possible)
2. tagging the new release in the repository (changes to release.h regarding the release type and release version are applied in this step)
3. exporting the new tag to local disk for packaging
4. creating two tarballs

Joe then has to manually handle the rest of the release procedure, such as uploading the files to the sourceforge.net File Release System.

When the tag is created in the repository, a new "version" will be added to Trac. So, as soon as the new release is tagged, users will be able to file tickets for this release version.

Give it a test

Those of you who have write access to the madwifi.org repository can play with the script in the playground I've set up at http://trac.madwifi-test.otaku42.de and http://svn.madwifi-test.otaku42.de.

Check out a working copy from the playground's latest trunk, then run "make release" inside the working copy. Use the same login credentials that you use for the main repository. Looking at the playground's Trac installation you will see that new releases will immediately be available in the "version" field for new tickets, for example.

Release planned for Monday (2006-05-29)

Given that there are no objections regarding the script/target and given that no-one speaks up and lets us know about things we have forgotten, I plan to commit the needed changes to the main repository next Monay (May 29th) and package our first release (yay!)

Ah, and of course:

Signed-off-by: Michael Renzmann <mrenzmann@otaku42.de>

Do we need to have:

#include "../../release.h"

and why not:

#include "release.h"

Revised patch, includes release.h without relative path stuff

Good point, no idea why I did it that way. Revised patch attached.

Will this stop the svn printouts from non-release tarballs? svnversion.h is still created, but I don't see how it is used in preference to release.h for builds from svn snapshots or working copies. Is it like this by design? Or am i simply not seeing something ;-)

Perhaps you meant to rename svnversion.h Makefile target to release.h?

In which case the kernel patch system will require a slight name adjustment.

Corrected diff which includes the previously missing changes to release.h

Oops, sorry, my bad. I forgot to include the very first changeset (which was the one implementing the changes to release.h) into the diff. madwifi-release-target-3 now should be correct, sorry for the confusion.

It works like this:
release.h now additionally provides RELEASE_VERSION. If MadWifi is built from either a working copy or a snapshot, svnversion.h is created; release.h includes svnversion.h and RELEASE_VERSION is set to the content of SVNVERSION. Releases won't have svnversion.h due to the forementioned changes, so make-release.bash modifies release.h such that it does not include svnversion.h and sets RELEASE_VERSION to the version of the release. The changes to release.h are committed when tagging the release, and after tagging make-release.bash reverts the changes in the local working copy.

Last but not least, version information printouts are no longer using SVNVERSION, but are switched to RELEASE_VERSION instead.

This way we have just one location in the source that needs to be adjusted when a release is tagged, which makes handling in the script a lot easier. And as a side effect release builds won't have a probably confusing svnversion.h file.

Ok, now I can see it. Thanks for clearing that up Mike.

Committed in r1590.

Wiki page for release checklist started as DevDocs/PreparingReleases. It needs further extension, but it's a start.

Closing this ticket in preparation of the 0.9.0 release.

For those who wait: the actual release will be delayed another 12 hours or so.

Sorry to be a pain, Mike, but my above comment about including release.h in the kernel patch install.sh system was not considered in the addition of the release mechanism which has undone some work from the last weekend (and I currently lack the time to fix that).

It would be great if you could get the patch done within the next hours, so we can get the release out of the door. If we don't make it today, it will have to wait until Monday (since I'll be offline until then).

Done.

Thanks, kelmo. Heading off to get the release out of the door now. Yeeehaaaarrr... :)