Facter ticket 'target version' experiment

[Jeff Weiss]

We're going to run an experiment with the Facter tickets which should help with:

1) A rough date of when we will release a specific version (i.e. 2.1.0)

2) The tickets we are actively working on for the next feature release (see roadmap for 2.1.0)

3) The tickets we are actively working on for the breaking change release (see roadmap for 3.0.0)

4) The tickets we think are a good idea, but not actively working on (currently the 'Accepted' state)

We are doing away with targeting 1.6.x or 2.x or 2.0.x because they've really just become dumping grounds of things that we'd like to get to, but probably won't anytime soon. We've also found the .x targets to be misleading communicating, internally and externally, what will be in an upcoming release and whether or not the issue is actively being worked.

Our experimental process will be this:

- Actively worked on features and bug-fixes will be targeted at the next feature release (2.1.0, 2.2.0, 2.3.0).

  - The code branch for the feature releases will be 2.x.

- At the time we go to cut a feature release, if the content is solely bug-fixes, we will downgrade to a bug-fix version number (e.g. 2.2.0 would become 2.1.1).

- Cut a feature release monthly

- Actively worked on breaking changes will be targeted at the next major release (3.0.0, 4.0.0, etc)

  - The code branch for the breaking change release will be master.

- Cut a breaking change release annually (we may cut development prereleases more frequently to facilitate feedback)

We believe this will help communicate the planned content of near-term releases, hopefully without the prior confusion about what exactly a target version means.

As always, we welcome feedback.

Best Regards,

Jeff Weiss

Software Developer

Puppet Labs, Inc.

jeff....@puppetlabs.com