kicad-doc-devs team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

There is a plan. Tag the source first, then have a grace period to
allow dependencies as libs, i18n and docs to check the last bits
before tagging. Packagers should just use the tags or tarballs when
ready.
On Thu, 11 Oct 2018 at 10:42, Carsten Schoenert <c.schoenert@xxxxxxxxxxx> wrote:
>
> Hi,
>
> Am 11.10.18 um 10:13 schrieb Nick Østergaard:
> > I don't see an advantage of creating a 5.0 branch before more issues are fixed
> >
> > https://github.com/KiCad/kicad-doc/issues
> >
> > We don't gain anything by having a 5.0 branch other than wasting
> > valuable time. IMHO.
>
> well, currently I see just more time wasting on my side because of
> confusion for me (and I'm probably not the only person here). And it
> will not getting better in the future by staying on the bridge in the
> middle.
>
> All the time we have talked about this is right now is more if it would
> have been done in the past. :-(
> kicad-doc is the same as the libraries, kicad-i18n, kicad-footprints ...
>
> Why not have a plan for this all and some straightforward way? Why do
> often FOSS projects do make not needed work like this here.
>
> Yes, KiCad 5.0.1 will be probably the last 5.0 release, but I also
> wouldn't bet on this. And the next goal will be 5.1.0 release. It's
> quite not logical fore me to do some argumentation like above given for
> the 4.0 release circle a branch was created anyway. Branches and Tags
> are cheap.
>
> Maintaining all the KiCad packages for Debian is already taking a lot of
> time, please don't make this more power consuming than necessary.
>
> --
> Regards
> Carsten Schoenert
>
> --
> Mailing list: https://launchpad.net/~kicad-doc-devs
> Post to     : kicad-doc-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-doc-devs
> More help   : https://help.launchpad.net/ListHelp