Security.md: include release candidate and snapshot information #2311

PhilipOakley · 2019-08-27T13:59:19Z

This should be a one commit adjustment to SECURITY.md to respond to comment #2303 (comment)

Provide details of the release candidate versions and snapshots ('nightlies', though they aren't).

Signed-off-by: Philip Oakley philipoakley@iee.email

hope the 'rc' comes through the .md filtering ok.

bbolli · 2019-08-27T14:52:39Z

SECURITY.md

+
+Git for Windows also releases versions that reflect the upstream release candidates, which contain the 'rc<n>' suffix to the regular git version, and before the 'windows' suffix. It should be noted that these rc version sort after their formal release, so appear to be newer to the updater software.
+
+(All releases)[https://github.com/git-for-windows/git/releases/] are listed via a link at the footer of the (Git for Windows)[https://gitforwindows.org/] home page.


I think markdown links are [formatted like this](https://help.github.com/en/articles/basic-writing-and-formatting-syntax#links). You did it the other way round.

@bbolli Thanks. I saw the one error in the CI but without any real diagnostics, wee not that I could understand. I found Is there any way to escape angle brackets, so I've just force pushed that.

But yes, it does look like I'd also got the URL []() the wrong way around

@bbolli Does the content, headings, etc. read OK?

rimrul · 2019-08-27T15:15:10Z

SECURITY.md

@@ -18,6 +18,14 @@ As Git for Windows bundles more than just Git (such as Bash, OpenSSL, OpenSSH, G

 Every Git for Windows version is tagged using a name that starts with the Git version on which it is based, with the suffix `.windows.<patchlevel>` appended. For example, Git for Windows v2.17.1' source code is tagged as [`v2.17.1.windows.1`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1) (the patch level is always at least 1, given that Git for Windows always has patches on top of Git). Likewise, Git for Windows v2.17.1(2)' source code is tagged as [`v2.17.1.windows.2`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2).

+## Release Candidates (rc) and Snapshot versions ('nighltlies')


Typo. Should be nightlies.

Oh rats. Many thanks, I, fix that. Does it read OK otherwise?

rimrul · 2019-08-27T19:17:25Z

SECURITY.md

@@ -18,6 +18,14 @@ As Git for Windows bundles more than just Git (such as Bash, OpenSSL, OpenSSH, G

 Every Git for Windows version is tagged using a name that starts with the Git version on which it is based, with the suffix `.windows.<patchlevel>` appended. For example, Git for Windows v2.17.1' source code is tagged as [`v2.17.1.windows.1`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1) (the patch level is always at least 1, given that Git for Windows always has patches on top of Git). Likewise, Git for Windows v2.17.1(2)' source code is tagged as [`v2.17.1.windows.2`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2).

+## Release Candidates (rc) and Snapshot versions ('nightlies')
+
+Git for Windows also releases versions that reflect the upstream release candidates, which contain the `rc<n>` suffix to the regular git version, and before the 'windows' suffix. It should be noted that these rc version sort after their formal release, so appear to be newer to the updater software.


Maybe an S at he end of "these rc version", but it reads good otherwise. Sorry I missed that the first time.

Ok, added the 's'.
Also added the leading '-' to the rc (as shown on the releases page).

I'm presuming the output of git version will also have the hyphen. It's probably what cause the sort order, which otherwise looks at the leading dot of '.windows' as the next character.

dscho

Almost there!

dscho · 2019-08-28T09:14:12Z

SECURITY.md

@@ -18,6 +18,14 @@ As Git for Windows bundles more than just Git (such as Bash, OpenSSL, OpenSSH, G

 Every Git for Windows version is tagged using a name that starts with the Git version on which it is based, with the suffix `.windows.<patchlevel>` appended. For example, Git for Windows v2.17.1' source code is tagged as [`v2.17.1.windows.1`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1) (the patch level is always at least 1, given that Git for Windows always has patches on top of Git). Likewise, Git for Windows v2.17.1(2)' source code is tagged as [`v2.17.1.windows.2`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2).

+## Release Candidates (rc) and Snapshot versions ('nightlies')
+
+Git for Windows also releases versions that reflect the upstream release candidates, which contain the `-rc<n>` suffix to the regular git version, and before the 'windows' suffix. It should be noted that these rc versions sort after their formal release, so appear to be newer to the updater software.


Maybe link to https://tinyurl.com/gitCal for the upstream release cycle? That would also give us an excuse to explain that Git for Windows tries to release new versions and prereleases as close to upstream Git, but they are not really tied together other than by convention.

As to -rc versions sorting incorrectly, this is arguably a bug in our installer, and I would love to see it fixed (hint: this is a really good opportunity to help).

I've had a quick look at the issue with rc versions and regular releases, and I think I see the issue (well, 2 issues) and have an idea for a fix. But let me recap the issue symptoms real quick, so I don't we're on the same page as to what we're talking about:

If you're on an rc version, say v2.23.0-rc1.windows.1 and the corresponding release version (v2.23.0.windows.1) gets released, git update-git-for-windows won't detect that as a newer version.

Did I understand that correctly? I usually skip the rcs, so I'm not quite sure.

Ok, reading Philips comment in #2312 I might have missunderstood the issue.

when upgrading from the rc build to the proper first release, you WILL get a dialog saying that it appears that you are down grading versions.

Hi @rimrul
I can't remember the exact sequence. I had one of the release candidates installed (I think I had both rc1 and rc2 as they came out and I was responding to the email announcements).

The formal release comes out and I get the next announcement (hence, I think, ahead of any daily check). I click some link, to bet to the announced release (here it is fuzzy).

I get the download from the appropriate page (I'm on Firefox) and it's stored into my downloads folder. View the downloads folder.

Run the download/installer. Installer warns that the release about to be installed is older than the current version - "Install anyway?" (or something like that). I install anyway.

That's the sequence, with some fuzzy 'didn't take notes at the time' inexactitudes.

Hope that helps.

Yes, that helps. The version comparison just compares each number (one or more digits separated by one or more non-digit character) in both version numbers. Thus it gets confused by rc versions having more numbers than regular releases.

dscho · 2019-08-28T09:16:19Z

SECURITY.md

+
+[All releases](https://github.com/git-for-windows/git/releases/) are listed via a link at the footer of the [Git for Windows](https://gitforwindows.org/) home page.
+
+Git for Windows also provides snapshots (these are not releases) of the progressing upstream development via the shears/* and vs/* branches and the [Snapshots](https://wingit.blob.core.windows.net/files/index.html) page. These snapshots contain the Windows specific patches via automated continuous integration. Link also at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


Actually, there are no snapshots for shears/*. There are only snapshots for our master.

At some stage in the future, I would like to get an Azure Pipeline going that automatically builds portable Git and MinGit versions whenever shears/* was updated and passes the test suite. This will require a bit of effort, and I do not have the time right now.

SECURITY.md

PhilipOakley · 2019-08-28T09:48:59Z

Ok, updated commit title fixup! ...
added the calendar link
snapshot only from master (I included the 'reponame'..)
noted rc sorting more softly.
tweaked sentences.
Force pushed. Hopefully done this 5 minute quicky patch 😉 ...

PhilipOakley · 2019-08-28T09:51:37Z

PS when the gibhub page shows "Changes requested ", do I need to anything with the "Resolve conversation" button?

Or is simple doing the action and force pushing to get the CI going again sufficient (along with a reply comment)?

rimrul · 2019-08-28T09:54:13Z

For that to change dscho will need to change his review from "Changes requested" to "approved". Nothing you can do.

dscho

I still find the last paragraph of the Release Candidates section mixing too many things. I'd like the topics to be separated better, and described clearer.

dscho · 2019-09-02T20:08:03Z

SECURITY.md

+
+[All releases](https://github.com/git-for-windows/git/releases/) are listed via a link at the footer of the [Git for Windows](https://gitforwindows.org/) home page.
+
+Git for Windows also provides snapshots (these are not releases) of the progressing upstream development from the gitforwindows/master branch at the [Snapshots](https://wingit.blob.core.windows.net/files/index.html) page, while the repository also provides the shears/* and vs/* branches. These snapshots contain the Windows specific patches via automated continuous integration. Link also at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


The way I read this paragraph, it is a bit misleading.

git-for-windows/master is not the upstream development. The upstream development happens in git/pu, git/next, git/master and git/maint. The git-for-windows/shears/* branches (e.g. git-for-windows/shears/pu) reflect the patch thicket of git-for-windows/master as rebased onto the corresponding upstream branch git/*.

Also, we should describe what the snapshots are ("These snapshots contain ...") directly after the link to the "Snapshots" page, without talking about the shears/* and the vs/* branches in between.

In fact, the information about the shears/* branches should be provided in a totally separate section, and vs/master should be mentioned in yet another section, as they serve very different purposes, and branches are simply totally different things than snapshots (the former consist of source code, under version control, the latter are binaries built from a specific revision).

dscho · 2019-09-02T20:12:20Z

SECURITY.md

+
+Git for Windows also releases versions that reflect the [upstream release candidates](https://tinyurl.com/gitCal). These contain the `-rc<n>` suffix to the expected regular git version, and before the 'windows' suffix. These releases are independent of upstream but are tied together by convention. It should be noted that these rc versions currently sort after their formal release, so appear to be newer to the updater software.
+
+[All releases](https://github.com/git-for-windows/git/releases/) are listed via a link at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


Maybe you could mention here that Release Candidates as well as MinGit backports are marked as "prereleases", so that the latest version will always be a stable, full Git for Windows?

Oh, and it would probably be a good idea to split out the section talking about the snapshot versions. They are built from master, are hosted somewhere completely different than the Release Candidates and the full Git for Windows releases, and at some stage in the future I might have to start garbage-collecting old snapshots, while I will never need to do that with the RCs/full versions. So they are quite different in nature, and hence would merit being handled in different sections.

dscho

Sorry, I still found things I really would like to be more accurate...

dscho · 2019-09-02T23:14:27Z

SECURITY.md

@@ -18,6 +18,20 @@ As Git for Windows bundles more than just Git (such as Bash, OpenSSL, OpenSSH, G

 Every Git for Windows version is tagged using a name that starts with the Git version on which it is based, with the suffix `.windows.<patchlevel>` appended. For example, Git for Windows v2.17.1' source code is tagged as [`v2.17.1.windows.1`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1) (the patch level is always at least 1, given that Git for Windows always has patches on top of Git). Likewise, Git for Windows v2.17.1(2)' source code is tagged as [`v2.17.1.windows.2`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2).

+## Release Candidate (rc) versions
+
+Git for Windows also releases versions that reflect the [upstream release candidates](https://tinyurl.com/gitCal). These contain the `-rc<n>` suffix to the expected regular git version, and before the 'windows' suffix. These releases are independent of upstream but are tied together by convention. It should be noted that these rc versions currently sort after their formal release, so appear to be newer to the updater software.


The .windows.<patchlevel> suffix only applies to the tag names, not to the Git for Windows version numbers...

The .windows.<patchlevel> suffix only applies to the tag names, not to the Git for Windows version numbers...

Not sure what you mean here, so can't begin to change anything. Do you want to suggest an alternate?

I was referring to this sentence:

These contain the -rc<n> suffix to the expected regular git version, and before the 'windows' suffix.

It makes it sound as if the .windows. infix is part of the version number, but it is not.

I have it (the .<rc<n>) as being between regular (upstream/linux) git (e.g. 2.22.0 and the .windows., so it is as I said. How would you phrase it?

But it is not between the regular version and .windows., because .windows. is not even part of the version number.

Talking about .windows. here is outright confusing.

I say again, How would you phrase it?

$ git version
git version 2.22.0.rc3.windows.1.380.gef5ddde56c.dirty

Users don't think about the Git for Windows version in terms of the output of git version, but in terms of the version provided on https://gitforwindows.org/, https://git-scm.com and https://github.com/git-for-windows/git/releases. There are no .windows. infixes there, nor funny .dirty suffixes. Ever.

So this is how I would have phrased it:

Git for Windows also publishes versions based on Git's release candidates (for upcoming ".0" versions, see Git's release schedule). These versions end in -rc<n>, starting with -rc0 for a very early preview of what is to come, and as with regular versions, Git for Windows tries to follow Git's releases as quickly as possible.

Note: there is currently a bug in the "Check daily for updates" code, where it mistakes the final version as a downgrade from release candidates. Example: if you installed Git for Windows v2.23.0-rc3 and enabled the auto-updater, it would ask you whether you want to "downgrade" to v2.23.0 when that version was available.

Of course, I had hoped that I would not need to spend time on phrasing this, I am not a native speaker after all ;-)

dscho · 2019-09-02T23:15:09Z

SECURITY.md

+
+## Snapshot versions ('nightlies')
+
+Git for Windows also provides snapshots (these are not releases) of the progressing upstream development from the gitforwindows/master branch at the [Snapshots](https://wingit.blob.core.windows.net/files/index.html) page. Link also at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


Let's call it git-for-windows:master, i.e. with the dashes. This corresponds to the way GitHub abbreviates <org-or-user>/<branch> when referring to branches in other forks.

Or just spell it out as "Git for Windows' master branch".

Likewise, the snapshots are not following upstream development. They are following Git for Windows' own development only, which is not based on upstream's master, but is rebased onto upstream's latest version instead, whenever a new one is made available.

dscho · 2019-09-02T23:18:23Z

SECURITY.md

+
+## Following 'upstream' developments
+
+The [gitforwindows/git repository](https://github.com/git-for-windows/git) also provides the shears/* and vs/master branches. These branches folow the upstream development in addition to the Windows specific patches via automated continuous integration. The vs/master branch is compiled via the MSVC tool chain.


s/folow/follow/

vs/master does not follow upstream development at all, but adds a commit on top of git-for-windows:master, providing the project files ready to build Git in Visual Studio. That branch is generated, but not compiled.

PhilipOakley · 2019-09-03T10:58:43Z

aren't we dropping into https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good land here for the incremental improvement and small changes that Git is meant to be ideal for.

Happy to accept your tweaks.

dscho · 2019-09-04T20:28:10Z

aren't we dropping into https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good land here

Not for the description of vs/master (characterizing it as following upstream is simply incorrect), and given that this document will be shown in the "Security" tab, I'd rather have it be correct, and I am willing to cook it longer until it is ;-)

PhilipOakley

Not a clue why the DCO says it wasn't signed off.

Needs more feedback of where the fault was. Hopefully attempt 3 at sticking superfluous blank lines will fix it.

PhilipOakley · 2019-09-23T22:39:40Z

Why is the DCO check failing?

dscho · 2019-09-24T15:57:50Z

Why is the DCO check failing?

When I look at this commit locally, it reads like this:

commit 613cca252a5889407afbb4e20243fb32da61354f
Author: Philip Oakley <philipoakley@iee.email>
Date:   Mon Sep 23 23:13:25 2019 +0100

    fixup! SECURITY.md: document Git for Windows' policies

    #8

        Signed-off-by: Philip Oakley <philipoakley@iee.email>

It seems that the "Signed-off-by:" line is indented for some reason. My guess is that the DCO check does not like that.

dscho · 2019-09-26T09:02:54Z

Why not squashing the two fixup! commits into a single one? They try to fix up the same commit, after all. And a bit of an explanation in the commit message would also be nice ;-)

As suggested in git-for-windows#2303 (comment): Also mention the release candidate and snapshot version numberings, e.g. that the final release's installer will claim that the release candidates are newer than the proper release. And also note the existence of the snapshots; This may encourage others to participate in the 'development'. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Fix a few more unclear/incorrect phrasings (while the perfect is the enemy of the good, the vague and the not-quite-right are the enemy of the good-enough). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Amended the changes myself

dscho · 2019-09-30T18:21:58Z

@PhilipOakley thanks for starting this!

PhilipOakley · 2019-10-02T09:28:03Z

Thanks.

Hopefully folks will contribute more refinements and clarifications as they occur.

PhilipOakley mentioned this pull request Aug 27, 2019

SECURITY.md: document Git for Windows' policies #2303

Merged

bbolli reviewed Aug 27, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch 2 times, most recently from 61304a7 to f69a3cb Compare August 27, 2019 14:59

rimrul reviewed Aug 27, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch from f69a3cb to c11c4ee Compare August 27, 2019 19:13

rimrul reviewed Aug 27, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch from c11c4ee to 6559eb9 Compare August 27, 2019 19:43

PhilipOakley mentioned this pull request Aug 28, 2019

Never finished downloading, Download says 64 bit, Task Manager says 32 bit #2312

Closed

dscho requested changes Aug 28, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch from 6559eb9 to ba60e84 Compare August 28, 2019 09:45

weekly-digest bot mentioned this pull request Sep 1, 2019

Weekly Digest (25 August, 2019 - 1 September, 2019) #2317

Closed

dscho requested changes Sep 2, 2019

View reviewed changes

dscho reviewed Sep 2, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch from ba60e84 to 2d1839a Compare September 2, 2019 21:42

dscho previously requested changes Sep 2, 2019

View reviewed changes

wuanna approved these changes Sep 4, 2019

View reviewed changes

weekly-digest bot mentioned this pull request Sep 8, 2019

Weekly Digest (1 September, 2019 - 8 September, 2019) #2324

Closed

PhilipOakley force-pushed the versionnumbers branch 2 times, most recently from c4d3d9d to 613cca2 Compare September 23, 2019 22:36

PhilipOakley commented Sep 23, 2019

View reviewed changes

PhilipOakley force-pushed the versionnumbers branch from 613cca2 to 71c7d18 Compare September 24, 2019 22:21

weekly-digest bot mentioned this pull request Sep 29, 2019

Weekly Digest (22 September, 2019 - 29 September, 2019) #2342

Closed

PhilipOakley and others added 2 commits September 30, 2019 20:05

fixup! SECURITY.md: document Git for Windows' policies

b7585cc

Fix a few more unclear/incorrect phrasings (while the perfect is the enemy of the good, the vague and the not-quite-right are the enemy of the good-enough). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho force-pushed the versionnumbers branch from 71c7d18 to b7585cc Compare September 30, 2019 18:20

dscho merged commit 8c5225c into git-for-windows:master Sep 30, 2019

weekly-digest bot mentioned this pull request Oct 6, 2019

Weekly Digest (29 September, 2019 - 6 October, 2019) #2350

Closed

dscho mentioned this pull request Nov 4, 2019

Rebase to Git v2.24.0 #2386

Merged


		Git for Windows also releases versions that reflect the upstream release candidates, which contain the 'rc<n>' suffix to the regular git version, and before the 'windows' suffix. It should be noted that these rc version sort after their formal release, so appear to be newer to the updater software.

		(All releases)[https://github.com/git-for-windows/git/releases/] are listed via a link at the footer of the (Git for Windows)[https://gitforwindows.org/] home page.

		@@ -18,6 +18,14 @@ As Git for Windows bundles more than just Git (such as Bash, OpenSSL, OpenSSH, G

		Every Git for Windows version is tagged using a name that starts with the Git version on which it is based, with the suffix `.windows.<patchlevel>` appended. For example, Git for Windows v2.17.1' source code is tagged as [`v2.17.1.windows.1`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.1) (the patch level is always at least 1, given that Git for Windows always has patches on top of Git). Likewise, Git for Windows v2.17.1(2)' source code is tagged as [`v2.17.1.windows.2`](https://github.com/git-for-windows/git/releases/tag/v2.17.1.windows.2).

		## Release Candidates (rc) and Snapshot versions ('nighltlies')


		[All releases](https://github.com/git-for-windows/git/releases/) are listed via a link at the footer of the [Git for Windows](https://gitforwindows.org/) home page.

		Git for Windows also provides snapshots (these are not releases) of the progressing upstream development via the shears/* and vs/* branches and the [Snapshots](https://wingit.blob.core.windows.net/files/index.html) page. These snapshots contain the Windows specific patches via automated continuous integration. Link also at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


		## Snapshot versions ('nightlies')

		Git for Windows also provides snapshots (these are not releases) of the progressing upstream development from the gitforwindows/master branch at the [Snapshots](https://wingit.blob.core.windows.net/files/index.html) page. Link also at the footer of the [Git for Windows](https://gitforwindows.org/) home page.


		## Following 'upstream' developments

		The [gitforwindows/git repository](https://github.com/git-for-windows/git) also provides the shears/* and vs/master branches. These branches folow the upstream development in addition to the Windows specific patches via automated continuous integration. The vs/master branch is compiled via the MSVC tool chain.

Security.md: include release candidate and snapshot information #2311

Security.md: include release candidate and snapshot information #2311

Conversation

PhilipOakley commented Aug 27, 2019

Signed-off-by: Philip Oakley philipoakley@iee.email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dscho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhilipOakley commented Aug 28, 2019

PhilipOakley commented Aug 28, 2019

rimrul commented Aug 28, 2019

dscho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dscho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhilipOakley commented Sep 3, 2019

dscho commented Sep 4, 2019

PhilipOakley left a comment

Choose a reason for hiding this comment

PhilipOakley commented Sep 23, 2019

dscho commented Sep 24, 2019

dscho commented Sep 26, 2019

dscho commented Sep 30, 2019

PhilipOakley commented Oct 2, 2019