After getting into the actual implementation of Facter 2, it turns out the original branch structure that I proposed would be more work than it would be worth to do. The original approach was to shift the 'master' branch into the 'next' branch and revert master to the current version of stable so that Facter could match the branching strategy that we use in our other projects. Upon attempting this, it turned out that doing this would create a colossal amount of churn in the code base and make it very unclear what was different between master and stable. While it would be nice to be consistent in our branch structure it looks like we would be better off leaving master as-is.
Instead of renaming master to next and synchronizing master with stable, instead we've created a new branch for the Facter 2 release, namely 'facter-2'. New features for Facter should be targeted at this branch, and the Facter 2.0 final release will be based off this code. Changes to stable will be merged into facter-2, and facter-2 will be merged up into master to keep the different branches in sync. In the long run we plan on incrementally backport commits from master to facter-2. When we've backported all the commits that we want to release in Facter 2, we'll revert any remaining changes in master that aren't in facter-2, and then merge facter-2 up into master. On Thu, Dec 19, 2013 at 12:33 PM, Adrien Thebo <[email protected]>wrote: > Is this with respect to the structure of the generated data, or the > structure of the Facter API itself? If it's the former, Facter will be able > to return simple data types that should be readily serializable in > different formats, so the output could be trivially serialized to JSON, > YAML, msgpack, and similar. I have a pull request that implements this > behavior at https://github.com/puppetlabs/facter/pull/575 . > > With respect to the API, that's yet to be exactly nailed down. The > `Facter.add` syntax will still be supported for compatibility, but we may > add a few aliases and methods to make things cleaner. Things get murkier > when you want to start composing multiple resolutions like what's described > in https://tickets.puppetlabs.com/browse/FACT-65 but I have a few > prototypes that make it possible by allowing resolutions to be extended. > I've attached an example of that to this email that has generally gotten > positive reviews. > > > > > On Thu, Dec 19, 2013 at 2:56 AM, Erik Dalén > <[email protected]>wrote: > >> Do you have any draft of what the structure will look like? >> >> Will it be much different from the overall structure of ohai? >> >> >> On 3 December 2013 23:27, Adrien Thebo <[email protected]> wrote: >> >>> Structured fact support in Facter has often been compared to unicorns >>> - long sought after, greatly desired, and nonexistent. There have been a >>> number of proposed implementations but none have managed to make it into >>> Facter - either the implementation was incomplete, changed too many things, >>> or just didn’t have follow-through. Structured fact support has also been a >>> hard requirement for Facter 2, which has meant that Facter 2 itself has >>> been in limbo for a long time. >>> >>> We’re hoping to change this state of affairs, and get a release of >>> Facter 2 out that contains structured facts. In order to get something out >>> in short order, the initial implementation will support simple data types >>> like arrays, hashes, strings, and numbers, and will support basic fact >>> composition. The idea is to get the core behavior released into the wild in >>> Facter 2, and add more functionality in the Facter 2.x series*. >>> >>> Normally the next major release of Facter would be based on master, but >>> doing so would make things more complicated. The master and stable branches >>> have been diverging for over a year, and master is 400 commits ahead of >>> stable. The stable branch has only been receiving bugfixes while the master >>> branch has been receiving features, but since master has been intended to >>> be Facter 2 it’s been receiving breaking features as well as non-breaking >>> features. We know the master branch will definitely break things, but we no >>> longer know exactly what it’s going to break. >>> >>> Because the state of master is so uncertain we’ve decided to base Facter >>> 2 off of stable. Structured facts will be implemented, but Facter 2 won’t >>> see a rewrite of all the core facts to minimize the changes released in >>> Facter 2. The goal is to base Facter 2 off a known release state and >>> minimize the amount of possible breaking changes so that the upgrade from >>> Facter 1 to Facter 2 is as painless as possible. Later in the 2.x series we >>> intend to start writing new core facts that take advantage to structured >>> data once the initial release has landed and works. >>> >>> Basing Facter 2 off of stable means that we will need to do some >>> reordering of the Facter branches. Our CI jobs currently test against the >>> master and stable branches, so in order to test Facter 2 against the rest >>> of our projects the master branch will need to be changed to the stable >>> branch, and the current state of master will be shifted to a new name. I >>> propose that we copy the master branch to a ‘next’ branch, and then revert >>> the master branch to stable and start work on Facter 2 from there. This >>> means that pull requests will be targeted at the right branch by default, >>> our CI jobs will continue to behave as normal, and we can synchronize our >>> branch strategy with Puppet and Hiera. >>> >>> Since there are a number of commits in Facter master that we’ve promised >>> will be in Facter 2, we’ll be backporting a number of changes from the next >>> branch to master. We want to keep the number of backported changes limited >>> to minimize the number of changes in Facter 2, but we realize that there >>> are changes that many of you have been waiting on for a while. If there are >>> specific commits that you really want to see in Facter 2, let us know and >>> we can see about getting them backported. And of course, once Facter 2 is >>> released we’ll be able to start putting out feature releases much more >>> quickly. If things don’t make it into Facter 2 then we can see about >>> getting features released in 2.1. >>> >>> * Tentative roadmap for upcoming Facter releases: >>> >>> >>> - >>> >>> 1.7.4 >>> - >>> >>> release date: mid-December >>> - >>> >>> base: current stable >>> - >>> >>> features: current stable + bugfixes for external facts (#22944, >>> #22622) >>> - >>> >>> 2.0.0 >>> - >>> >>> release date: mid-January >>> - >>> >>> base: current stable >>> - >>> >>> features: structured facts + short list of candidates from >>> (current) master >>> - >>> >>> 2.1.0 >>> - >>> >>> release date: TBD >>> - >>> >>> base: future master >>> - >>> >>> features: more facts from (current) master, select facts >>> rewritten as structured facts >>> >>> >>> -- >>> Adrien Thebo | Puppet Labs >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/CALVJ9SLgwxvxatn0JMHer3JHV2sQrCQYOS%2BNmzT2puzHOd8shQ%40mail.gmail.com >>> . >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Erik Dalén >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfcef2q0e0M7CZKYhCyMg8VRJsp7XuXLe%3DFuR8qtuOD7g%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Adrien Thebo | Puppet Labs > -- Adrien Thebo | Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALVJ9SLe53d07D%2BuKdy7fO28YPxdi9FbzHhCMrBeX6MjsQHi4g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
