I think this emphasizes the point that we need to understand and
document a release requirements and procedure that is 100% consistent
with Apache requirements BEFORE we begin having low level discussions
on how to implement that release procedure. ...
I think that the first question we would need to answer in a discussion
of the releases is, "What is the form of the release that is seen by the
user?" In the past, that was:
1. Two separate versioned tarballs, one for apps/ and one for nutts/
2. ReleaseNotes, and
3. A tagged repository.
The creation of the tarballs was done by the script tools/zipme.sh.
That script requires the version number and the commit UID at the HEAD
of the nuttx/ repository (addressing Justin's concern with tags). It
generates the tarballs and also a .version file in the root. That
.version file contains the versioning information in various formats as
well as the UID. The .version file is directly include-able by scripts
and Makefile fragments. At build time, the .version is used to create
an include/nuttx/version.h header file making the version information
available to C and C++ code as well.
Releases were posted on SourceForge and Bitbucket download areas.
Release announcements were made in the NuttX Google group and in the
LinkedIn NuttX group.
That is what the world is used to. Do you see things that should
change? Probably the repository tags would become branches and
locations where releases are available would change. But other than
that, is there any reason why anything else change? Certainly, there
should be no artificial coupling been apps/ and nuttx/. I believe that
those must stay independent.
Does Apache have any requirements that we must follow for how releases
are made available?
Greg
