delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/12/23/23:03:29

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] [pcb] Plans for Next Release of pcb
In-Reply-To: <CAJZxidC0MFi9oN94eYdSoeN4gfQ7hfUgm4EskmH5x3Y56Wpx2w@mail.gmail.com> (geda-user@delorie.com)
Date: Fri, 23 Dec 2016 23:02:18 -0500
Message-ID: <xnbmw2otyt.fsf@envy.delorie.com>
MIME-Version: 1.0
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

"Chad Parker" writes:
> 1. What to do about version numbering

The snapshot scheme is easier but that doesn't mean a full X.Y.Z release
shouldn't be done eventually.  We've not had many "revolutionary"
changes that would require us to tell the users "it's not backward
compatible any more" (4.x) or "forward-incompatible changes" (1.99++)
etc.

Doing a release is pretty easy, we can do one a week if we wanted.
Deciding when to release and what to put in it is much harder ;-)

> 2. What additional changes to include in the release

For the most part, bug fixes we have, and make sure new features aren't
in the middle of being added, so that it at least works.  It's never
been something we worried heavily about, as we can always do a follow-on
release if needed.


> 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?

Yes, yes, right, yup, no.

> 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'm all for "release what we have, release more later when we have it"
rather than wait.  Releases are too far apart to worry that we're not
releasing often enough ;-)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019