The hash tag is in the revision string as well, so as long as the
revision string is supported we know exactly which commit was
used to build.
- Cirilo
On Sun, Aug 28, 2016 at 2:02 AM, Bob Gustafson wrote:
> On 08/27/2016 10:55 AM, Chris Pavlina wrote:
>
> On Sat, Aug 27, 2016 at 05:48:45PM +02
I'm out of town for the weekend. If I have time tomorrow when I get
home, I will try to create the source archive and make the release
announcement. If I don't get it done tomorrow, it will happen early in
the week.
Cheers,
Wayne
On 8/27/2016 10:10 AM, Eldar Khayrullin wrote:
> What status of
rev 1234 the same meaning as rev 67230ac, you have to look it up
regardless on git.
On Sat, Aug 27, 2016 at 11:48 AM, jp charras wrote:
> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
>> Now that we've migrated from bzr, there isn't much reason to keep
>> attaching a (now fake) bzr revision numb
On 08/27/2016 06:06 PM, Chris Pavlina wrote:
> Sure, if you're trying to pin down an _exact_ commit...but how does the
> fake bzr revno help you there? The bzr repo isn't used anymore, it's not
> like you can just check the bzr log for it.
>
> All you need is a sense of how old it is. If you need
On Sat, Aug 27, 2016 at 11:48 AM jp charras wrote:
> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
> > Now that we've migrated from bzr, there isn't much reason to keep
> > attaching a (now fake) bzr revision number to the version string.
> > Additionally, we can choose a sensible default branch
On Sat, Aug 27, 2016 at 11:02:49AM -0500, Bob Gustafson wrote:
> On 08/27/2016 10:55 AM, Chris Pavlina wrote:
>
> >On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras wrote:
> >>Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
> >>>Now that we've migrated from bzr, there isn't much reason to keep
>
On 08/27/2016 10:55 AM, Chris Pavlina wrote:
On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras wrote:
Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
Now that we've migrated from bzr, there isn't much reason to keep
attaching a (now fake) bzr revision number to the version string.
Additional
On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras wrote:
> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
> > Now that we've migrated from bzr, there isn't much reason to keep
> > attaching a (now fake) bzr revision number to the version string.
> > Additionally, we can choose a sensible default
Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
> Now that we've migrated from bzr, there isn't much reason to keep
> attaching a (now fake) bzr revision number to the version string.
> Additionally, we can choose a sensible default branch name if one isn't
> specified on the cmake line, rather than
Now that we've migrated from bzr, there isn't much reason to keep
attaching a (now fake) bzr revision number to the version string.
Additionally, we can choose a sensible default branch name if one isn't
specified on the cmake line, rather than "product". This patch reformats
the version strings to
What status of release v.4.0.4? Can I use the tag 4.0.4 to create
package?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : ht
11 matches
Mail list logo
