> On 19 Dec 2018, at 10:58, Alistair Grant wrote:
>
> Hi Sven,
>
> On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe wrote:
>>
>>
>>
>>> On 19 Dec 2018, at 08:50, Alistair Grant wrote:
>>>
>>> Hi Sven,
>>>
>>> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote:
I
Hi Sven,
On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe wrote:
>
>
>
> > On 19 Dec 2018, at 08:50, Alistair Grant wrote:
> >
> > Hi Sven,
> >
> > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote:
> >>
> >> I know about master and what it means, but that is not exactly what I
> On 19 Dec 2018, at 08:50, Alistair Grant wrote:
>
> Hi Sven,
>
> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote:
>>
>> I know about master and what it means, but that is not exactly what I want.
>>
>> When you release, that is a deliberate action: you put a stamp on the
>>
Hi Sven,
On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote:
>
> I know about master and what it means, but that is not exactly what I want.
>
> When you release, that is a deliberate action: you put a stamp on the current
> project timeline, declaring it as ready/stable enough for
> On 18 Dec 2018, at 17:34, Ben Coman wrote:
>
> To understand for future reference, just curious what you ended up doing.
> At https://github.com/svenvc/ztimestamp/releases
> I see the v24 tag is commit ee31f06
>
> but at https://github.com/svenvc/ztimestamp/network
> I see the
To understand for future reference, just curious what you ended up doing.
At https://github.com/svenvc/ztimestamp/releases
I see the v24 tag is commit ee31f06
but at https://github.com/svenvc/ztimestamp/network
I see the latest-release branch is commit b18dfdf
It looks like you v24 of
> On 18 Dec 2018, at 16:41, Sven Van Caekenberghe wrote:
>
> I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7
https://github.com/svenvc/ztimestamp/commit/2eadc5d1730ca24d2a946b7b7bbb6b195c8759c8
is a commit that changes ConfigurationOfZTimestamp by adding a version 24
Ben, Torsten,
I decided to go for the branch option,
https://github.com/svenvc/ztimestamp/tree/latest-release
I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7
Thanks for all the help.
> On 18 Dec 2018, at 16:29, Torsten Bergmann wrote:
>
> Ben wrote
>> "If the tag is
Ben wrote
>"If the tag is edited on the server, but the local one is old"
Yes - there could be an issue with this "tag moving" approach if the server is
not checked
for new tags / moved tags and the version from the local repo cache is loaded -
because
you might load an outdated while the
> On 18 Dec 2018, at 14:23, Ben Coman wrote:
>
>
>
> On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo wrote:
> El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe
> () escribió:
> >
> > So let us agree on the best name then, to minimise confusion going forward.
> >
> > I am not sure I
On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo
wrote:
> El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe
> () escribió:
> >
> > So let us agree on the best name then, to minimise confusion going
> forward.
> >
> > I am not sure I would go for camel case, git is typically lowercase (or
>
JOKING:"lastRelease" is fine, there is no release afterwards anymore as it
is completed by 100% ;)
SERIOUS: "latest-release" seems appropriate
El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe
() escribió:
>
> So let us agree on the best name then, to minimise confusion going forward.
>
> I am not sure I would go for camel case, git is typically lowercase (or so it
> feels), I agree 'release' should be part of the name, so
>
>
So let us agree on the best name then, to minimise confusion going forward.
I am not sure I would go for camel case, git is typically lowercase (or so it
feels), I agree 'release' should be part of the name, so
last-release
latest-release
lastRelease
latestRelease
What say you ?
> On 18 Dec
ocally - remember to push the tags afterwards. Double
> checking afterwards in GitHub helps
> here. The command
>
> git push -f --tags
>
> could be helpful here.
>
> Hope this solves what you require.
>
> Thanks
> Torsten
>
>
>
>
>
>
>
>&g
On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe wrote:
> I am trying to load https://github.com/svenvc/ztimestamp/releases/latest
> which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24
>
> The following works because that is the whole idea of releases (which are
> just
here. The command
git push -f --tags
could be helpful here.
Hope this solves what you require.
Thanks
Torsten
> Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr
> Von: "Sven Van Caekenberghe"
> An: "Pharo Development List"
> Betreff: Re: [Phar
> On 18 Dec 2018, at 12:48, Torsten Bergmann wrote:
>
> Hi Sven,
>
> did you try to just use the branch name as in the other model.
>
> Metacello new
> baseline: 'ZTimestamp';
> repository: 'github://svenvc/ztimestamp:master';
> load.
>
> then it should load the latest from this
Hi Sven,
did you try to just use the branch name as in the other model.
Metacello new
baseline: 'ZTimestamp';
repository: 'github://svenvc/ztimestamp:master';
load.
then it should load the latest from this branch independent from the
tags.
Bye
T.
I am trying to load https://github.com/svenvc/ztimestamp/releases/latest which
is actually https://github.com/svenvc/ztimestamp/releases/tag/v24
The following works because that is the whole idea of releases (which are just
tags)
Metacello new
baseline: 'ZTimestamp';
repository:
--- Begin Message ---
I believe it is important to remove obsolete entries in the catalog. Having a
new empty MetaRepo for each Pharo version seems like a good strategy.
Forcing people to republish their configurations when necessary is a good
filtering mechanism.
Cheers,
Alexandre
> On Dec
On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe wrote:
>
>
> > On 17 Dec 2018, at 20:18, Torsten Bergmann wrote:
> >
> > Model 1: Work with a single branch and close a release using a tag as
> version in git
> >
>
> On 17 Dec 2018, at 20:18, Torsten Bergmann wrote:
>
> Model 1: Work with a single branch and close a release using a tag as version
> in git
> ===
> This is I guess how Iceberg, Calypso and others are
On Tue, 18 Dec 2018 at 03:19, Torsten Bergmann wrote:
>
> Model 2: Work with several open branches - one per Pharo version
>
>
> In DesktopManager which is on
> https://github.com/astares/Pharo-DesktopManager I do it differently. I
gt; As no tagging with explicit versioning is involved here the branch for each
> Pharo version is always open for new
> additions/future fixes.
>
> The first model is close to what one is used to from the past: having
> reproducible fixed tagged versions referenced
> from the C
le bit. If not just ask.
Have fun
T.
> Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr
> Von: "Sven Van Caekenberghe"
> An: "Pharo Development List"
> Betreff: [Pharo-dev] Catalog Entries
>
> Hi,
>
> So we have the Catalog with version specific
Hi,
So we have the Catalog with version specific repositories for
ConfigurationOfXYZ packages/classes.
I am assuming that we will be keeping this system for at least Pharo 7 and
possibly 8.
Can one define Catalog entries using BaselineOfXYZ ?
Is that recommended ?
Or should a mostly empty
27 matches
Mail list logo
