Dan-

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

All-

<= /div>

Would it be worth creating a blueprint on launchpad to help manag= e 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 additi= onal changes to include in the release

3. (anything else?)

For versioning it seems we have two choices:
1. r= elease date-stamped snapshots, or
2. return to version numbers.
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.
=

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.=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.

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've only had maybe 1 patch release in the last decade.= =C2=A0 The reality is in the past we didn'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.

-Dan

--047d7b3a896293f0f405445c6933--