This package dev is fine with you waiting a few days for 4.0.4, but
let's not stretch out much more than that.
On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina
<pavlina.chris@xxxxxxxxx
<mailto:pavlina.chris@xxxxxxxxx>> wrote:
On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh
wrote:
> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > Hi, Wayne!
> >
> > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> >> I wasn't planning on migrating the stable 4 branch to
git. I'm hoping
> >> there wont be too many more 4 stable releases so I'm not
sure it's worth
> >> the effort.
> >
> > Ok, I was wondering...
> > I was missing the stable branch, too - as well as all the
tags of the old
> > releases, etc. I personally don't need them, but it could
be useful
> > and interesting to get all former references (r6994, rev
6994, 4.0.0-rc...)
> > migrated over to the git side once.
>
> My one gripe about git is the commit hash tags. They really
are not
> very user friendly. The tags you mention above are all in 4
stable
> branch so if you continue to use bzr for the stable 4
branch, you should
> not have any issues. I will tag future stable versions in
git when we
> get to that point so you will be able to use git tags in the
same
> manner. I'm not sure how maintaining a stable branch in git
is going to
> work. I'm guessing that it will be a completely separate
repo like we
> do with bzr but I'm going to worry about that when the time
comes.
As for the hashes not being user-friendly...well, that's what
tags are
for! Commits aren't really sequential anyway, since you can do
all sorts
of weird stuff with branching and merging, so bzr's sequential
numbers
do start to fall apart once you do that. When you have code
you think is
ready for public release, tag it!
We could even do a 'testing' series, where we move commits
from devel
that are mostly okay, and tag a testing 'release' roughly
weekly or so
with a simple incrementing version number - this would be a
nice middle
ground between stable, which honestly starts to get a bit
stale, and
devel which occasionally breaks.
This could even then be used as a staging ground for things to
be
brought into the stable branch, allowing a somewhat smoother
release
cadence.
Pardon me, I'm just daydreaming a bit... :)
>
> >
> > Regards,
> >
> > Clemens
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> > More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
