X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=qCIzeQAUKfHw1nSuJpWkd/SiuU2jsSPBzMXAMQbhZp0=;
	b=Y8uGQEARPJ+thUb7qmRv0z1hq3/tZKxWUAHP6ojYBdwlX4moxlcPWJvYRaDc8l7Hd7
	L0ZhUbFu3AJRjqDhKk3tFg69RLc7QOJy3P+0FnHAedQ/9qOu+txADp2FNDTZMp7UfIO4
	MV0uqT8AyGBjnBAvLphn27oCVLwpvVkjj+mgzugOwRfzcA3B3Lg0aLfQNH817xt9CEOm
	4NxpdE96Vj2OldB4NJVEOUM54hAjxMNYiTTgwQJs76v6fyf+/PoU3SkwMQIX2ie61koY
	OpswAMxuXhwR9ByzduRUtc1Se84KWQ4uhBKd1JtlpI7LOH9HNqNW2u+qK8T6iFSe+ljF
	KD3g==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=qCIzeQAUKfHw1nSuJpWkd/SiuU2jsSPBzMXAMQbhZp0=;
	b=oLYRuRIYIO9107JkhCD6ti74ljNaA73d0p7ehluW5yph3uv1cTsSAcojE0C6Wd+0oA
	G2I13pToMQOK/ZDcm/RHtV8L+OUmUnVe0aRdiRCApE9x2tW69wXQE/nzkslknY0f4WcT
	kHMzJJx5yrr3tkS8lfObAboyORopQ+T9h3Wj/lG3V631ZbgU+fipYznv6zH7PA2D6CFC
	XCJF7cUqLR8oIuuVW9C7T/o2Ro+YJdzGrndxdkFhc5PthOdtOwPsAexrAlCuXIHsbiBM
	wH/7tVDasnFMUxOGBYS+Sh8YOUUkmqqghYP3GnOdsCxaH6HYMZg0NaFvHUzKc1+1byzT
	F7Yw==
X-Gm-Message-State:	AIkVDXJ3YNjNyj5vh3XKEjhpI+UNTeJLwmGK02JfcETSEsPsf73vxkKRtnjZHdgL6mdotARRSW5Lod7Hl/g62g==
X-Received:	by 10.194.209.169 with SMTP id mn9mr14790747wjc.114.1482538582534;
	Fri, 23 Dec 2016 16:16:22 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<bd246b73-ffa9-72df-5c42-ab04aa6b9b65@mcmahill.net>
References:	<CAJZxidDy5HcLZivqc5w+cnv716EFNLXKJdKXo+jDPMDVrJb2=Q AT mail DOT gmail DOT com>
	<585ADD79 DOT 3020403 AT xs4all DOT nl> <bd246b73-ffa9-72df-5c42-ab04aa6b9b65 AT mcmahill DOT net>
From:	"Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Fri, 23 Dec 2016 19:16:21 -0500
Message-ID:	<CAJZxidC0MFi9oN94eYdSoeN4gfQ7hfUgm4EskmH5x3Y56Wpx2w@mail.gmail.com>
Subject:	Re: [geda-user] [pcb] Plans for Next Release of pcb
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--047d7b3a896293f0f405445c6933
Content-Type: text/plain; charset=UTF-8

Dan-

Thanks a lot for pointing that out, and for whatever portions you
contributed. I'm a little embarrassed that I completely missed that readme.
It seems like a procedure has been documented in detail. I'll try to do a
dry run through it while we work through some of the other questions.

All-

Would it be worth creating a blueprint on launchpad to help manage this
process and these details? Is that appropriate?

There are a few things that (I think) we need to decide on:
1. What to do about version numbering
2. What additional changes to include in the release
3. (anything else?)

For versioning it seems we have two choices:
1. release date-stamped snapshots, or
2. return to version numbers.

My preference (realizing that I have no seniority and that my preference
carries very little weight) would be to go with version numbers, and use
the standard major.minor.revision scheme, making the next one 2.0.0. Then
maybe we can do more frequent revision releases to push out the bug fixes.
We can then do release candidates for the major or possibly minor releases.

DJ, is this what you were referring to as pcb-3.x?
http://opencircuitdesign.com/pcb/
Is this another pcb fork? They couldn't even change the name? That seems
like bad form to me, or am I missing something about the history?

Regarding additional changes, my opinion (again, realizing that carries
little weight) is to push all outstanding bug fixes to a future release,
and only incorporate changes directly related to the release, such as
fixing compile warnings and getting make distcheck to run cleanly.

I'd like to push this forward, so, if you have opinions, please speak up.

--Chad


On Fri, Dec 23, 2016 at 5:01 PM, Dan McMahill (dan AT mcmahill DOT net) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> On 12/21/2016 2:52 PM, Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via
> geda-user AT delorie DOT com] wrote:
>
>> Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
>>
>
>
> I wanted to start this thread to collect ideas and generally figure
>>> out how to execute this process, and hopefully push it forward. Being
>>> a relatively new developer to the project, I'm not entirely sure
>>> what's involved. So, let's start with some questions:
>>>
>>> Is there already a process in place for executing a release of pcb (or
>>> other gEDA tools)?
>>>
>>
> Yeah, I'm in the same situation ... never done a pcb release.
>>
>>
> yes, for pcb there is a documented procedure.  There is a readme in the
> top level of the source tree.  I tried to strictly follow it and when
> needed, update the document to match what was actually done on all the
> snapshots I did in the past.  Note that the procedure was done in CVS days
> and may need some additional tweaking in the git world although I think it
> has been updated for git.  It is important that we follow the procedure
> because it does catch (and has caught) some relatively minor issues which
> can cause real grief if not done.
>
> Historically we have not done release candidates for pcb.  I have created
> release branches but these have largely just been a stake in the ground
> with patch releases reserved for major screw ups like a missing source file
> in the distribution (which would be caught by the release procedure) or
> catastrophic failure.  I think between pcb and gerbv (which uses the same
> procedure) we've only had maybe 1 patch release in the last decade.  The
> reality is in the past we didn't anticipate having the manpower to maintain
> a release branch as well as the main development.  That is why pcb releases
> have been called snapshots.
>
> -Dan
>
>

--047d7b3a896293f0f405445c6933
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Dan-<br><br></div>Thanks a lot for poi=
nting that out, and for whatever portions you contributed. I&#39;m a little=
 embarrassed that I completely missed that readme. It seems like a procedur=
e has been documented in detail. I&#39;ll try to do a dry run through it wh=
ile we work through some of the other questions.<br><br></div>All-<br><br><=
/div><div>Would it be worth creating a blueprint on launchpad to help manag=
e this process and these details? Is that appropriate?<br></div><div><br></=
div><div>There are a few things that (I think) we need to decide on: <br></=
div><div>1. What to do about version numbering<br></div><div>2. What additi=
onal changes to include in the release<br></div><div>3. (anything else?)<br=
></div><div><br></div>For versioning it seems we have two choices: <br>1. r=
elease date-stamped snapshots, or <br>2. return to version numbers. <br><br=
>My preference (realizing that I have no seniority and that my preference c=
arries very little weight) would be to go with version numbers, and use the=
 standard major.minor.revision scheme, making the next one 2.0.0. Then mayb=
e we can do more frequent revision releases to push out the bug fixes. We c=
an then do release candidates for the major or possibly minor releases.<br>=
<br></div>DJ, is this what you were referring to as pcb-3.x?<br><a href=3D"=
http://opencircuitdesign.com/pcb/">http://opencircuitdesign.com/pcb/</a><br=
><div><div><div>Is this another pcb fork? They couldn&#39;t even change the=
 name? That seems like bad form to me, or am I missing something about the =
history?<br><br></div><div>Regarding additional changes, my opinion (again,=
 realizing that carries little weight) is to push all outstanding bug fixes=
 to a future release, and only incorporate changes directly related to the =
release, such as fixing compile warnings and getting make distcheck to run =
cleanly.<br></div><div><br></div><div>I&#39;d like to push this forward, so=
, if you have opinions, please speak up.<br><br></div><div>--Chad<br></div>=
<div><br></div></div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Dec 23, 2016 at 5:01 PM, Dan McMahill (<a href=3D"=
mailto:dan AT mcmahill DOT net">dan AT mcmahill DOT net</a>) [via <a href=3D"mailto:geda-=
user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr">&lt;<a href=
=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
12/21/2016 2:52 PM, Bert Timmerman (<a href=3D"mailto:bert DOT timmerman AT xs4all=
.nl" target=3D"_blank">bert DOT timmerman AT xs4all DOT nl</a>) [via <a href=3D"mailto=
:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Chad Parker (<a href=3D"mailto:parker DOT charles AT gmail DOT com" target=3D"_blank">=
parker DOT charles AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com"=
 target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
</blockquote>
<br>
<br>
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
I wanted to start this thread to collect ideas and generally figure<br>
out how to execute this process, and hopefully push it forward. Being<br>
a relatively new developer to the project, I&#39;m not entirely sure<br>
what&#39;s involved. So, let&#39;s start with some questions:<br>
<br>
Is there already a process in place for executing a release of pcb (or<br>
other gEDA tools)?<br>
</blockquote></blockquote>
<br>
</span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, I&#39;m in the same situation ... never done a pcb release.<br>
<br>
</blockquote>
<br></span>
yes, for pcb there is a documented procedure.=C2=A0 There is a readme in th=
e top level of the source tree.=C2=A0 I tried to strictly follow it and whe=
n needed, update the document to match what was actually done on all the sn=
apshots I did in the past.=C2=A0 Note that the procedure was done in CVS da=
ys and may need some additional tweaking in the git world although I think =
it has been updated for git.=C2=A0 It is important that we follow the proce=
dure because it does catch (and has caught) some relatively minor issues wh=
ich can cause real grief if not done.<br>
<br>
Historically we have not done release candidates for pcb.=C2=A0 I have crea=
ted release branches but these have largely just been a stake in the ground=
 with patch releases reserved for major screw ups like a missing source fil=
e in the distribution (which would be caught by the release procedure) or c=
atastrophic failure.=C2=A0 I think between pcb and gerbv (which uses the sa=
me procedure) we&#39;ve only had maybe 1 patch release in the last decade.=
=C2=A0 The reality is in the past we didn&#39;t anticipate having the manpo=
wer to maintain a release branch as well as the main development.=C2=A0 Tha=
t is why pcb releases have been called snapshots.<br>
<br>
-Dan<br>
<br>
</blockquote></div><br></div>

--047d7b3a896293f0f405445c6933--

- Raw text -