X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <5866DF50.1050809@xs4all.nl> Date: Fri, 30 Dec 2016 23:27:28 +0100 From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] [pcb] Plans for Next Release of pcb References: <74d9e3df-7aaa-cb29-5584-8c52d19227b1 AT sbcglobal DOT net> <585E6661 DOT 8070806 AT xs4all DOT nl> <2778f2e7-cd44-7823-a80b-a6ca0635c9f8 AT iee DOT org> <51bfdfb7-e4fd-c3c8-2a9b-3abd99ad37de AT fastmail DOT com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > Is the reason people want to skip to version 4 just because of that > fork that claimed version 3.x? If so, we could still use the 2.x.x > series before having to worry about the naming collision, and then > skip to 4.0.0. Or is it that we want to tell prospective users that > ours is better by having a higher version number? > > DJ- > I agree that there haven't been any changes that would break backward > compatibility, but sometimes you just have to make a clean break, like > when the kernel went to 3.0.0. > > Bert- > Thanks, I can be a little OCD sometimes, and I do like things to be > neat and clean! Particularly when it comes to plans. > > I sort of assumed that we would either have the code sprint earlier, > or not have one this month since the last Sunday of the month > (tomorrow) is Christmas day and I imagine that a lot of people will be > observing that holiday. > > I'll run through the release procedure that Dan pointed out sometime > in the next couple of days and let folks know how things go. I think > there are at least a couple of compile warnings on my Mac that will > need to be fixed. > > Cheers, and have a good holiday to all those who are celebrating. > --Chad > > > > > On Sat, Dec 24, 2016 at 3:01 PM, Girvin Herr > (girvin_herr+gherr_lists AT fastmail DOT com > ) [via > geda-user AT delorie DOT com ] > > wrote: > > > > On 12/24/2016 04:50 AM, M. J. Everitt (m DOT j DOT everitt AT iee DOT org > ) [via geda-user AT delorie DOT com > ] wrote: >> As a prospective proxy maintainer for Gentoo, please let me know >> when you roll a tarball, and I'll run through the Gentoo >> packaging process, and do some preliminary build/run-testing and >> feed back. >> > If wanted, I can do the same for a Slackware Linux package. I am > currently running Slackware 14.1 (k3.10.103), but I have a copy of > the latest 14.2 and plan to install it early next year. The only > change I can see is that the package architecture went from i486 > in 14.1 to i586 in 14.2, but that is trivial. Of course, the > dependencies have changed. > > Another option would be to contact the SlackBuilds.org pcb package > maintainer, Felix Pfeifer: pfeifer [dot] felix [at] googlemail > [dot] com > He might be willing to do this task and put the resulting packages > on SlackBuilds. > > geda-gaf on SlackBuilds.org seems to be maintained by a different > maintainer, Stephen Van Berg: stephen_van_berg at earlicker dot com > >> I would second a more consistent version numbering system, as >> this makes version-tracking easier for packagers too, so pcb v4 >> would indeed be a good choice if settled upon! > Consistency, yes. But the form doesn't matter for Slackware > packaging. x.y.z is just as fine as yyyymmdd. The only caveat is > that dashes may not be used in the version string. I usually > change them to underscores or remove them entirely if in yyyy-mm-dd. > > Girvin Herr > >> >> Good luck, thanks, and keep us posted on the list :) >> >> Michael. >> >> On 24/12/16 12:23, Peter Clifton (petercjclifton AT googlemail DOT com >> ) [via >> geda-user AT delorie DOT com ] wrote: >>> Nice to hear work is going on with mainline pcb as well... >>> >>> One thing prior to release. We ought to git rm the debian >>> directory that added to the repository. >>> >>> This matches preferred distro policy, and makes life easier for >>> the official packagers (so they can use our sources directly >>> without having to repackage them to remove the debian dir. >>> >>> I checked this with our debian packagers some while back to >>> confirm, but never got around to making the delete. >>> >>> Peter >>> > > Hi Chad, I see you are busy with the 4.0.0. test drive in your "home/cparker/4.0.0" branch. AFAICT some of those commits should be in master, others should go in a "pcb-4.0.0" release branch once you have finished testing. One other thing is that I found is that "make check" fails on the MinMaskGap test ... in a pristine Ubuntu 12.04 (precise) environment, see https://travis-ci.org/bert/pcb/builds and https://bugs.launchpad.net/pcb/+bug/1653280. I think we need to squash this bug before we can ship 4.0.0 ("make check" failing can be seen as "bad form"). I will keep you informed about any findings in the bug report. Kind regards, Bert Timmerman.