[Gt-eos] ready to tag

Fri Nov 2 12:50:28 CET 2018

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).

	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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5032 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/discuss/attachments/20181102/429408de/attachment.p7s>