[Gt-eos] ready to tag

Fri Nov 2 14:07:26 CET 2018

Hi Mattias, all,

On 11/2/18 12:50, Mattias Ellert via Gt-eos wrote:
> Hi!
> 
> Can we come to some kind of decision? I would like to package the
> changes made to the sources since the last tag, and the way it is set
> up now source tarballs are not created unless there is a tag. If it
> drags out for a long time I could make package updates using patches,
> but I think we can avoid that.
> 
> Regarding the toolkit version number: It should be 6.something -
> otherwise the https://repo.gridcf.org/gct6/sources/ address no longer
> makes sense and we would have to do quite a lot of changes.
> 
> The number 6.0 appears in a few places in the packaging files, so if we
> stick to that no changes are needed. If we choose 6.1 or 6.2, a few
> changes are needed, but it would be manageable (those changes should be
> done before tagging though).

I'm ok with both 6.0 and 6.2. But my preference would be 6.2 actually, 
although we could still postpone 6.2 until after end of 2018 and stay 
with 6.0 for now.

So your decision.

Cheers,
Frank

> 
> 	Mattias
> 
> mån 2018-10-22 klockan 10:12 -0500 skrev Mátyás Selmeci via Gt-eos:
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Gt-eos mailing list
>> Gt-eos at mailman.egi.eu
>> http://mailman.egi.eu/mailman/listinfo/gt-eos
> 
> 
> _______________________________________________
> Gt-eos mailing list
> Gt-eos at mailman.egi.eu
> http://mailman.egi.eu/mailman/listinfo/gt-eos
> 

-- 
Frank Scheiner

High Performance Computing Center Stuttgart (HLRS)
Department Project User Management & Accounting

Email: scheiner at hlrs.de
Phone: +49 711 685 68039

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