Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: how we handle "releases" #54

Thorin-Oakenpants opened this issue Mar 12, 2017 · 1 comment


Copy link

commented Mar 12, 2017

EDITED: 15-03-2017

"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 changelog label, so people can use +label%3Achangelog to pull up a running history (although we will have only one open, and a backlog of closed ones).

--typical timeline (example 53->54)--

  • -x days
    • we have 53->54 diffs issue in advance, we know a lot of what will be coming, and can prepare etc
  • -4 or -2 or -1 days:
    • create a 53 release for archive/legacy
    • change master to version 54-beta, set new date, set new code name & lyric
    • start commits for 54
  • D-Day
    • 54 stable lands from Mozilla
  • +4 days or +10 days (i.e when we have finished the 53->54 diffs)
    • close diffs 53->54 issue
    • update date in master and change to version 54
    • create a 54-alpha release
    • generate a diff (53-alpha->54-alpha)
    • from the above diff, create a changelog: 54-alpha as an open issue
    • close changelog: 53-alpha issue
    • ghacks does an article a day or two later
  • repeat cycle

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.

@Thorin-Oakenpants Thorin-Oakenpants changed the title feedback wanted: how to handle "releases" updated: how we handle "releases" - pics to follow Mar 14, 2017
@Thorin-Oakenpants Thorin-Oakenpants changed the title updated: how we handle "releases" - pics to follow FYI: how we handle "releases" Mar 16, 2017
@ghacksuserjs ghacksuserjs locked and limited conversation to collaborators Apr 2, 2017

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2017

.ie, nothing will change for weeks and weeks on end.

lulz ... wishful thinking :) I'm closing this - its been hanging around for 5 and 1/2 months

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
1 participant
You can’t perform that action at this time.