[Pharo-dev] Catalog Entries
akgrant0710 at gmail.com
Wed Dec 19 04:58:56 EST 2018
On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> > On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710 at gmail.com> wrote:
> > Hi Sven,
> > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven at stfx.eu> 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 people to depend on.
> >> The master branch can further evolve after a (latest) release. It is the next release candidate.
> >> I would like to depend on whatever released version is the latest. See the URLs in my previous email.
> > I think your understanding of master is different from mine. master
> > should never be the next release candidate, it is only ever the latest
> > GA code.
> > In that case, you can use master to mean "the latest GA version".
> > If you want release candidates, they should be branches off
> > development (or tags).
> > If you want to support multiple versions, e.g. be able to release a
> > 4.1 after 5.0 has been released, then each version should be branched
> > off master (at the GA commit for that version).
> > If you want to know where a named GA version is (and there won't be
> > further updates), it is a tag on the master branch.
> I don't think/believe there is only one right way to use git, that is part of its power.
Agreed, and I can see how you read my reply that way, but I didn't
mean to imply that "this is the one and only right way to do it".
> In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO.
OK, so what I understand you're try to achieve is to have a "released"
version and a "released and better tested" version.
Doesn't this run the same risk of people just sticking to the
"released and better tested" version, so the "released" version never
gets the additional testing that's desired?
> I also want to make things as simple as possible.
More information about the Pharo-dev