[Gt-eos] ready to tag

[Mátyás Selmeci]

Hi Mischa and folks,

I _really_ do not want to go backwards in versions.  I'm sure people
have scripts that check for $GLOBUS_VERSION and do one thing if it's
>= 6.0 and another if it's < 6.0.  I don't want to mess up those scripts.

We don't have to worry about conflicting with a Globus 6.1 or 6.2
release because:

1. We've been updating our repo to keep up with their repo.  If they
make a 6.2, then our 6.2 will incorporate their changes.

2. They've been on 6.0 since _2014_.  They haven't bumped the version
even when they added features.  Now they're in bugfix-only mode so
they won't be adding features either.

3. We can ask the Globus developers if they're OK with us calling our
version 6.2.

Thanks,
-Mat


-------- Original Message --------
From: Mischa Salle
Sent: Sun, Oct 21, 2018 4:04 AM CDT
Subject: [Gt-eos] ready to tag

Hi all,

We have a few options each with pros and cons:
- 6.1 is logical, but used to indicate development version (see
  http://toolkit.globus.org/toolkit/downloads/
  We don't have to keep to that schema (Linux kernel also dropped it),
  but it could be confusing.
- 6.2 is then more logical, but both still have the problem that there
  is indeed a small chance that Globus will still release something, a
  final release or so (although I very much doubt that). OTOH, we're
  called gct, not globus_toolkit, so I personally think 6.something
  should be fine.
- 1.0 has none of the above problems, we can also decide then to
  continue with 1.1 as the next stable (minor)release. Problem is that
  we have already a gct-6.0.1536386276 as a prerelease.
Ideally I think Globus shouldn't have been using 6.0.XXXX as a
prerelease but something like 6.0.0-XXXX, which works better with a sort
and is consistent with typical debian and rpm numbering.

I think I personally would prefer to move to a gct-1.0.0 combined from
now on with 1.0.0-$(date +%s) for the development releases.

Cheers,
Mischa


On Fri, Oct 19, 2018 at 06:13:16PM +0200, End of Support of Globus
Toolkit wrote:
> Hi all,
>
>> Now that Mattias has made EPEL and Debian packages from the current
>> builds, I think we're finally ready to tag a release. Does anybody have
>> an objection to the version 6.0.1? I'd like to keep the "6.0" for now to
>> emphasize that we're still compatible with that version of the Globus
>> Toolkit.
>
> Will there be a Globus 6.1 or 7.0 at some point, that some of our customers
> could be exposed to?  If so, it would lead to confusion sooner or later.
>
> Should we better start our releases with 1.0.0 instead and mention desired
> compatibility details in the release notes?

On Fri, Oct 19, 2018 at 11:34:27AM -0500, End of Support of Globus
Toolkit wrote:
> Sorry, looks like we might not be able to use 6.0.1 because the "micro"
> version number is actually the timestamp of the latest commit, which
> gets added to the version of the "gct" tarball.
>
> The version "6.0" gets embedded in several places in the code, most
> notably as the GLOBUS_VERSION environment variable and the script
> "/usr/bin/globus-version", so we'll have to try out 6.1 first to make
> sure it doesn't cause any problems.
>
> -Mat
>
> -------- Original Message --------
> From: Mátyás Selmeci
> Sent: Fri, Oct 19, 2018 10:53 AM CDT
> Subject: ready to tag
>
> Hi all,
>
> Now that Mattias has made EPEL and Debian packages from the current
> builds, I think we're finally ready to tag a release. Does anybody have
> an objection to the version 6.0.1? I'd like to keep the "6.0" for now to
> emphasize that we're still compatible with that version of the Globus
> Toolkit.
>
> Thanks,
> -Mat
>
>
>



> _______________________________________________
> Gt-eos mailing list
> Gt-eos at mailman.egi.eu
> http://mailman.egi.eu/mailman/listinfo/gt-eos





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4181 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20181022/ba75f959/attachment.p7s>