Semantic versioning + tagging releases

[misscs]

Vision

• Tag each release following semantic versioning guidelines.
• Maintain a release log using Github. This is a great example from NPM project

The goal of tagging releases is to:

1. Provide a clear overview of changes
2. Provide clearer path to contribution
3. Organize major releases (ex. name branches after the release and ability to use labels or milestones in issue tracker to group by major release)
4. Easier to release updates incrementally and roll back if necessary

[misscs]

Hi, @colinmegill:

What are your thoughts on this ticket? I was thinking we could start by tagging what's in master as 1.0.0. And branch:explainer as 2.0.0.

I am assuming that branch:explainer is the next big update of changes (correct me if I'm wrong). I think it will be clearer for contributors if we use major versions names for branches. Here's an example from Gulp project.

[colinmegill]

Sounds good to me! On Sun, Oct 1, 2017 at 10:52 AM claudina sarahe [email protected] wrote:

Hi, @colinmegill https://github.com/colinmegill:

What are your thoughts on this ticket? I was thinking we could start by tagging what's in master as 1.0.0. And branch:explainer as 2.0.0.

I am assuming that branch:explainer is the next big update of changes (correct me if I'm wrong). I think it will be clearer for contributors if we use major versions names for branches. Here's an example from Gulp project https://github.com/gulpjs/gulp/tree/4.0.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pol-is/issues/issues/66#issuecomment-333393986, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsDGVu3B3ay-Hn56fjOkbBgSiDFC0y7ks5sn9FCgaJpZM4Pp8fe .

[misscs]

👍 Great. I'll go ahead and do that. Is it correct to assume then that what is live is master? Or has code from branch:explainer been deployed to pol.is?

[mbjorkegren]

You can find out the currently deployed version of clientAdmin and clientParticipation by typing version into the js console on the page. for clientParticipation for clientAdmin The last part of the string is the git hash.

[misscs]

Thanks, @mbjorkegren. Quite helpful.

So code is being deployed from explainer branch. This is the latest commit. Thus, it isn't really a release branch, right?

Can you clarify the relation between explainer and master. Is explainer the new master?

[mbjorkegren]

Yeah explainer should really be merged into master.

[misscs]

@mbjorkegren cool. would you be willing to tackle that? then we could either just do a branch per feature against master and/or a release branch for any larger features that the team wants to bucket into a major release. thoughts?

[misscs]

then i start a branch for pol-is/polis-issues#69 off master, too :)

[colinmegill]

I will take that merge On Sun, Oct 1, 2017 at 12:18 PM claudina sarahe [email protected] wrote:

then i start a branch for pol-is/polis-issues#69 https://github.com/pol-is/issues/issues/69 off master, too :)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pol-is/issues/issues/66#issuecomment-333399767, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsDGS9dRzEtmj4rKi1Y2gn6zY8mTE9Fks5sn-VqgaJpZM4Pp8fe .

[colinmegill]

Unless @mbjorkegren is ok with creating a branch at Master for posterity and resetting master to explainer, lmk On Sun, Oct 1, 2017 at 12:19 PM Colin Megill [email protected] wrote:

I will take that merge On Sun, Oct 1, 2017 at 12:18 PM claudina sarahe [email protected] wrote:

then i start a branch for pol-is/polis-issues#69 https://github.com/pol-is/issues/issues/69 off master, too :)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pol-is/issues/issues/66#issuecomment-333399767, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsDGS9dRzEtmj4rKi1Y2gn6zY8mTE9Fks5sn-VqgaJpZM4Pp8fe .

[misscs]

@colinmegill you mean basically making explainer the new master? You could cut a tag for master at its current position.

[mbjorkegren]

@misscs I just merged explainer into master, should be ok to branch off master now

[colinmegill]

👍🏻 On Sun, Oct 1, 2017 at 1:31 PM mbjorkegren [email protected] wrote:

@misscs https://github.com/misscs I just merged explainer into master, should be ok to branch off master now

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/pol-is/issues/issues/66#issuecomment-333404588, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsDGYIsr1awsHYKstG0cgnquTYTfv5Aks5sn_a6gaJpZM4Pp8fe .

[patcon]

I like everything about this thread! Yay!

[crkrenn]

+1

Q: Why is this email [hopefully] five sentences or less? A: http://five.sentenc.es

From: cs [email protected] Reply-To: pol-is/polisServer [email protected] Date: Saturday, May 9, 2020 at 7:30 PM To: pol-is/polisServer [email protected] Cc: Subscribed [email protected] Subject: [pol-is/polisServer] Semantic versioning + tagging releases (#160)

Vision

• Tag each release following semantic versioninghttp://semver.org/ guidelines.
• Maintain a release log using Github. Thishttps://github.com/npm/npm/releases is a great example from NPM project

The goal of tagging releases is to:

1. Provide a clear overview of changes
2. Provide clearer path to contribution
3. Organize major releases (ex. name branches after the release and ability to use labels or milestones in issue tracker to group by major release)
4. Easier to release updates incrementally and roll back if necessary

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/pol-is/polisServer/issues/160, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABOJ5V7XWYN4GLPXEAIC4JLRQYGSJANCNFSM4M5BSLOA.

[patcon]

I'm with you in most of those perks!

3. Organize major releases (ex. name branches after the release and ability to use labels or milestones in issue tracker to group by major release)

I believe there was talk in chat between @colinmegill and @ballPointPenguin about simply cutting a tagged release from mainline like clockwork every x many weeks. (Will try to find and link here)

I'm personally in favour of that, instead of bundling features into releases in some pre-planned way. I prefer the idea of releases being a boring automated technical event, rather than a cultural event :)

[ballPointPenguin]

I prefer the idea of releases being a boring automated technical event, rather than a cultural event :)

I agree with this sentiment.

The convo w/ colin was a suggestion that edge.pol.is could host a nightly build, cut automatically at midnight or something (by some definition of "midnight"). In my interpretation, this is mostly unrelated to releases or versioning. I don't have a good reference for how "nightlies" are managed in successful projects, but my best guess is that they are not versioned releases, just a git_hash or timestamp, and there may well be many "nightlies" that are identical.

[patcon]

Re: nightlies. Oh yeah, that was a neat part of convo. Git hash or consecutive build numbers (or both) are what I've seen

We should prob summarize/link that convo in the build server issue too...