I love your answers they are straight to the point, easy to understand and
very useful, this one is no different, thank you :)
I have another questions but I will make a separate thread for it so its
easier for users to google and search for it, including me .
By the way the official docs are onl
Kilon,
I don't use tags a lot in my own projects, but if someone is using your
project in a production situation, then using tags is a good idea (if
you follow semantic versioning) so that the users can tell when and if
you have made api-breaking changes...
Since the Smacc project looks like
On 1/27/15 7:10 AM, Thierry Goubier wrote:
Hi Dale,
The wildcards on tags, are they available on branch names as well?
The wildcards are only applied to tags ... branch names are not expected
to look like version numbers with `.` and `-` separated "possibly
numeric" fields.
I wonder about
No I have not used git tags so far, so I am not familiar with them. But I
will keep in mind, I am considering not having versions at all, I find it a
curious concept.
Dale there is one thing I wanted to ask you , would it possible put in my
github repo installation instructions for installing prer
Kilon,
One more point that you might find useful ... If you use tags (i.e.,
v1.0.0, v1.0.1, v1.1.0), you can specify tag wildcards in the branch
field of the github repository description.
Using Thierry's example the following resolves the latest commit on the
master branch (bleeding edge):
Hi Dale,
The wildcards on tags, are they available on branch names as well?
I wonder about the choice for ? and *, because:
- In RE(s), ? is 0 or 1 occurence, * is 0 or any number of occurences.
- In shells (bash?), ? is any one character, * is 0 or any number of
characters.
i.e. ? matches less
beautiful it worked like a charm following your instructions , I now can
brake my project to smaller ones, each one with each own github repo and
use Baselines to load each one and still allow the user to load my Project
in one single click from Configuration Browser. Love it how Pharo make this
al
Hi Kilon,
a simple way to do that is to change your configuration so that it uses the
baseline in your github. The SmaCC configuration for Pharo 4.0 is written
in this way for the stable version.
version204: spec
spec
for: #'pharo4.x'
do: [
spec
