Mail Archives: geda-user/2016/12/30/17:29:30
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
> <mailto:girvin_herr%2Bgherr_lists AT fastmail DOT com>) [via
> geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>]
> <geda-user AT delorie DOT com <mailto: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
> <mailto:m DOT j DOT everitt AT iee DOT org>) [via geda-user AT delorie DOT com
> <mailto: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
>> <mailto:petercjclifton AT googlemail DOT com>) [via
>> geda-user AT delorie DOT com <mailto: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.
- Raw text -