bug#62509: 30.0.50; Changes to naming for Windows stapshots - PATCH

[Corwin Brust <corwin@bru.st>]

On Fri, Sep 1, 2023 at 2:39 PM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Corwin Brust <corwin@bru.st> writes:
>
> >
> > Locally, my snapshots, instead of any date, include the git revision
> > short-code effective in the source tree where the build is taking
> > place, e.g.:
> >   emacs-30-28a9438169f-no-deps.zip
> >
> > TIA for sharing your thoughts; I can easily rename files, including
> > those already posted if necessary.
>
> How about
>
>     emacs-30-YYYY-MM-DD-REVISION-no-deps.zip.

I'd prefer not; however, it seems possible you can see use from the
date there which I cannot.

From my standpoint, it is challenging to pick the date to use.  I do
most releases for GNU rather manually, and might take a day or two
doing it. Is there information to be gained from knowing the "build
start date" (but not time?) that isn't better sourced by git log
<REVISION>?

Moveover, considering viewing a given version subfolder over HTTP,
sorting by the date column must surely give the same order as name
after adding this, reducing the utility of sorting by name that
otherwise helps quickly find binaries corresponding to a given
revision.

In any case, although I don't prefer it, it is not a problem to resume
including a common date in the file names constituting a release given
I know what date to use.

>
> @@ -91,4 +100,4 @@ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  GNU General Public License for more details.
>
>  You should have received a copy of the GNU General Public License
> -along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> +along with GNU Emacs.  If not, see https://www.gnu.org/licenses/.
> \ No newline at end of file
>

Yes, thanks; I see to that in a next version once we've confirmed on
how to name the files :blush: