Release management

After a long time working with enyo 2.4.0 it looks like I'm now finally have time to upgrade my current project to a newer enyo version and this seems like as good a time as any to ask a question that's been burning in my mind for some time:

What's up with enyo's release management??

If I check out the website, the latest officially released version is 2.5.1, with 2.5.1.1 as official addendum. Based on this, the stable version to upgrade to would be v2.5.1.1.

However, looking on github, there are already a 2.5.2 tag, there are 2.5.3 pre-release tags but no 2.5.3 release, there are 2.5.4 pre-release tags but no 2.5.4 release and finally pre-releases for version 2.6. Then there are also some 'lite' releases as well, which I have no idea what that means...

So, if go by tags on github, the latest stale release not marked with any dev, pre or rc flags, is 2.5.2.

Perhaps, in light of all the efforts being made to create some more structure around enyo (new docs, efforts to improve community interaction, I think I read something about better testing, etc.) perhaps this would also be a good time to add some structure to enyo's release management?

Perhaps it's a good idea to have some clear messaging on which version is officially supported (including important bug-fixes). Also, maybe some rules on what triggers a version bump from 2.5.x to 2.5.y and what triggers a version bump from 2.x to 2.y?

Intuitively a version bump without dev, pre-release or release-candidate flags would imply:
- updated docs
- updated changelog
- an official public release
- official support (things like emergency bug-fixes such as 2.5.1.1)

If one or more of these things cannot be supplied, I would think it should be a release-candidate at best.

Can someone from the enyo team shed some light on this?

Comments

  • I wanted to let you know that we haven't forgotten about this thread. Gray Norton is putting together a reply that will address the issues you raised.
  • Thanx for the update Roy, looking forward to it :)
  • edited March 2015
    Hi, Ruben -

    Good observations and questions...
    If I check out the website, the latest officially released version is 2.5.1, with 2.5.1.1 as official addendum. Based on this, the stable version to upgrade to would be v2.5.1.1.
    Yes -- 2.5.1.1 is the most recent public release. If you are looking to update a released app to the latest version, that's the one we'd recommend.
    However, looking on github, there are already a 2.5.2 tag, there are 2.5.3 pre-release tags but no 2.5.3 release, there are 2.5.4 pre-release tags but no 2.5.4 release and finally pre-releases for version 2.6. Then there are also some 'lite' releases as well, which I have no idea what that means...

    So, if go by tags on github, the latest stale release not marked with any dev, pre or rc flags, is 2.5.2.
    Most of the releases you see tagged on GitHub are driven by internal customers at LG. The needs and priorities of our internal customers often differ from those of the "Enyo public," and they generally have strict schedule requirements that we need to meet.

    These internally-driven releases come in (at least) three varieties:

    * Patch releases (changes to the third digit of the version number). Internal patch releases get "final" (non-suffixed) version numbers because they will reach LG customers in some form, but they tend to focus on issues specific to an LG product, and to originate from branches that are already behind master. Generally speaking, you should just ignore these releases. We don't officially release them to the public because their limited value doesn't justify the significant additional effort -- primarily in the form of cross-platform testing -- that goes into preparing an official release. Any useful fixes in these releases end up in master as well, which puts them on the public release train.

    * Pre-releases of the next version (changes to the first or second digit, with a suffix of "pre" or "rc"). These releases generally contain new features or improvements of interest to the Enyo public, but a) they are not likely to have received cross-platform testing; b) features are subject to be incomplete or broken; and c) while there are detailed release notes, there generally won't be any of the high-level positioning or context-setting that we try to do when issuing a public release. You are welcome and encouraged to keep an eye on these pre-releases, as long as you understand the limitations.

    * Major or minor releases (changes to the first or second digit, without suffix). In an ideal world, these would always be issued as official public releases as well, but in reality we usually have to "ship" a major or minor release in support of a webOS platform release or an LG product release before we have time to do the extensive cross-platform testing, polishing of docs and samples, crafting of public communications, etc., that go into an official public release. As with patch releases, you should essentially ignore any final releases that we don't announce on the Enyo site as official public releases. Our current policy is to issue a public release as quickly on the heels of an internal final release as we can; Enyo 2.4.0 and Enyo 2.5.1 are examples of this practice. (Enyo 2.4.0 got its own minor version number because we added some new functionality and introduced some API changes in parallel with the cleanup and testing.)
    Perhaps, in light of all the efforts being made to create some more structure around enyo (new docs, efforts to improve community interaction, I think I read something about better testing, etc.) perhaps this would also be a good time to add some structure to enyo's release management?
    As I hope became clear from the above, there is actually quite a bit of structure to our release management. There are things we don't like about it, of course; we'd ultimately like to have our internal and external release trains converge, and we're doing our best to move in that direction. For example, we're investing in more / better automated testing that we can run against all of our target platforms, which should reduce the amount of time-consuming manual work that currently goes into a public release. But some of our challenges have to do with structural issues in the way we work with our internal customers. We can't address those unilaterally, so I think it will probably be quite some time before we get where we want to go.
    Also, maybe some rules on what triggers a version bump from 2.5.x to 2.5.y and what triggers a version bump from 2.x to 2.y?
    We are inspired by and adhere loosely to the principles of Semantic Versioning. A patch release (third-digit change) will generally contain only bug fixes and should be completely backward compatible with the preceding release. We break from strict Semantic Versioning in that we reserve first-digit changes for significant generational shifts, whereas Semantic Versioning calls for a first-digit change whenever there is a breaking change of any kind. We strive to avoid breaking changes in minor releases, and to clearly document them when we can't avoid them, but when we call a release Enyo 3 it will be because it's significantly, qualitatively different from Enyo 2, not because we changed an API.
    Intuitively a version bump without dev, pre-release or release-candidate flags would imply:
    - updated docs
    - updated changelog
    - an official public release
    - official support (things like emergency bug-fixes such as 2.5.1.1)

    If one or more of these things cannot be supplied, I would think it should be a release-candidate at best.
    The standards you describe are essentially our standards for an official public release; it's just that, as explained above, our internal customer relationships often require us to "ship" releases that don't meet all of these standards.

    Because that's the case, you should think of the Enyo site and forums, not tags on GitHub, as the "source of truth" with respect to official releases.

    Hope this helps...
  • Hello Gray,

    Thank you for a very complete and clear explanation. I see now there is a lot more structure to the release management that's not immediately clear when only looking at github tags alone.

    I can understand internal clients often put very different constraints on releases than the official public ones, so all of that makes good sense really. Seems that, for production software, the docs are leading then.
Sign In or Register to comment.