Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
FYI: how we handle "releases" #54
"releases" are end of stable-life-cycle for archival/legacy purposes (with all the benefits of being fully up-to-date with any changes including vetting/testing/feedback over the life-cycle, as well as typos, extra items, revamps, whatever).
"pre-releases" - An important milestone for end users is knowing when the master becomes "version compliant" - and that point is when we have finished all the diffs generated by earthlng's diff script. The closer we are to when that version lands from Mozilla, the better. To let users know (because a closed "ToDo: Diff" issue doesn't necessarily cut it), we have the changelog (a more user friendly version of what's happening as compared to an atomic level commit history). This is also the basis for ghacks doing a 6 weekly article as a follow up to his 6 weekly "What's new in FFxx". This is good for feedback, knowledge for end-users, and also drawing contributors and users here. In order for earthlng to generate the changelog, he needs two points. And for all the reasons you would expect, having those snapshot points stored here makes sense. But we will use a "pre-release" tag.
Note, we also have a
--typical timeline (example 53->54)--
Throughout the entire life-cycle, we will make changes as required. Typos, new reference sources, revamps, changing items active status, and so on.
Note: The "release" and "alpha release" descriptions make it clear what they are. If end users choose to download the "alpha release" zip, even weeks after it has been created, then that's their problem. The master is always current stable, and always being improved. It will however, become a bit more of a moot point as this js reaches finalization and there's nothing more to do except version changes - .ie, nothing will change for weeks and weeks on end.