On 3/1/16 4:02 PM, Justin Mclean wrote:
Hi,
Great summary!
0.8.0-b1 is exceptional in that it is our first release. In subsequent
releases we will want to specify what has been added or fixed since the
last release, as well as highlight known issues.
JFYI this is usually done in a separate file call RELEASE_NOTES or similar. For
example see [1] but there no prescribed way of doing this it’s up.
yes. I think next release has to spend quite a bit of time on this
file, given the early state of OS releases, we need to be super clear
with people about where we are.
(4) Fix our release naming procedure.
Again up to the PMC how they name releases, other than having the project name,
‘incubating’ and (optionally) apache. “rc" (for release candidate) is usually used
rather than "b” tends to be typical but again totally up to the PMC. That those
names seem fine to me.
Having the release process documented would be a good idea so that other
committers can make a release if they want.
+1. I think we'll need to document two things on the Mynewt wiki,
branching strategy and release process.
1- We should document the current release process that we used, along
with thoughts on the improvements
2- I'll work on documenting our branching strategy.
I think there are a number of things we'll want to discuss re [1],
including:
- How do we manage non-ASF compatible packages. Do they get distributed
on Github, and does the ASF repository point to these external packages.
What type of warnings do we want to provide in the Newt tool for non-ASF
compatible licenses.
- Do we want to have a list of these 3rd party package repositories in
the official ASF documentation?
- How do we provide binary and source distributions of the Newt tool.
My instinct is that close to 99% of our users will take the newt binary
as opposed to source, so we need to make this easy, while still
following the ASF philosphy of source first releases.
- How do we want to allow people to access the ASF package repository
with releases of newt. For example, by default should a newt release
point to a specific tag on the incubator-mynewt-larva package
repository? Should we allow people to chose different versions based on
a tag / branch strategy here?
- How do we facilitate upgrade of packages when migrating to a new release.
Chris, if you take a first pass at this with what we've done for this
release, I can take a second pass, and then let's send around to the
list for discussion?
Cheers,
Sterling
