On 08/03/2019 21:41, Wayne Stambaugh wrote:
> Tom,
>
> On 2/22/2019 10:17 AM, Tomasz Wlostowski wrote:
>> On 21/02/2019 21:21, Wayne Stambaugh wrote:
>>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>>> major merges are ready to go once 5.1 is branched. I know Jon's
Hey Jeff,
As long as that is the case, then I will add this to the merge priority
list.
Cheers,
Wayne
On 3/8/2019 3:42 PM, Jeff Young wrote:
> Hi Wayne,
>
> I’d argue no, but it’s not black-and-white. Everything will be backwards
> compatible with the proviso that if you enter a character
Duh! Nevermind, I already replied to this.
On 3/8/2019 3:40 PM, Wayne Stambaugh wrote:
> Seth,
>
> On 2/21/2019 10:16 PM, Seth Hillbrand wrote:
>> Am 2019-02-21 15:21, schrieb Wayne Stambaugh:
>>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>>> major merges are ready
Hi Wayne,
I’d argue no, but it’s not black-and-white. Everything will be backwards
compatible with the proviso that if you enter a character in 6.0 that is
excluded from 5.1 (say, “data:1”) and then read it in to 5.1, it will display
escaped (“data{colon}1” in our example).
And if, for some
Tom,
On 2/22/2019 10:17 AM, Tomasz Wlostowski wrote:
> On 21/02/2019 21:21, Wayne Stambaugh wrote:
>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>> major merges are ready to go once 5.1 is branched. I know Jon's netlist
>> code is ready to merge and I'm pretty sure
Seth,
On 2/21/2019 10:16 PM, Seth Hillbrand wrote:
> Am 2019-02-21 15:21, schrieb Wayne Stambaugh:
>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>> major merges are ready to go once 5.1 is branched. I know Jon's netlist
>> code is ready to merge and I'm pretty sure
This will require some more discussion to see how it may or may not
impact the new constraint management system. I'm not opposed to it but
it will require a bit of coordination with the devs who are working on
the new constraint system.
On 2/21/2019 9:04 PM, hauptmech wrote:
> I have a patch for
Jeff,
Wont this effectively change the schematic file format? If so, then it
will have to wait until the new schematic file format is implemented. I
don't want to make any changes to either that or the symbol file format
so the legacy file format parsers can be frozen for all posterity once
the
Hi Cedric,
On 26.02.19 06:55, cedric.dew...@telfort.nl wrote:
> I'm opposed to any program that modifies a file when I open it.
> In my opinion the file should only change when I press the
> "save" button.
Of course, we'd have to ask first. The advantage would be that
developers] V6 merge update
Many of the professional CAD packages do this and it makes
collaboration with people that need to run an older version more
difficult.
--
Hi Simon
I'm opposed to any program that modifies a file when I open it. In my opinion
the file should only cha
Many of the professional CAD packages do this and it makes collaboration
with people that need to run an older version more difficult.
On 23/02/2019 10:48 AM, Simon Richter wrote:
Hi Seth,
On 22.02.19 18:11, Seth Hillbrand wrote:
It should be easier for new features as they don't need the
This would also show people that something is happening to their file on
load.
On Fri, Feb 22, 2019, 3:48 PM Simon Richter
wrote:
> Hi Seth,
>
> On 22.02.19 18:11, Seth Hillbrand wrote:
>
> > It should be easier for new features as they don't need the wrap the
> > parsing in versioning checks;
Hi Seth,
On 22.02.19 18:11, Seth Hillbrand wrote:
> It should be easier for new features as they don't need the wrap the
> parsing in versioning checks; especially for semantic changes. It may
> be more effort when changing underlying structures that are shared
> between parsers.
Would it make
Am 2019-02-22 09:29, schrieb Wayne Stambaugh:
Once v6 is started, I'd like to freeze the v5 parsers and make a copy
of
the parsers for v6. This would mean that all new format features
would
be implemented in a separate parser while any changes to underlying
structures would require updates in
On 21/02/2019 21:21, Wayne Stambaugh wrote:
> Since we are nearing the 5.1.0 release, I want to get an idea of what
> major merges are ready to go once 5.1 is branched. I know Jon's netlist
> code is ready to merge and I'm pretty sure that should be the first big
> merge. Does anyone else have
On 2019-02-22 5:20 a.m., Eeli Kaikkonen wrote:
At the minimum I would appreciate if clear notice is given when a new file
format change is introduced and how it affects compatibility.
The mentions of upcoming file format changes raises the question of whether
the file format document is up to
Hey Seth,
On 2/21/2019 10:16 PM, Seth Hillbrand wrote:
> Am 2019-02-21 15:21, schrieb Wayne Stambaugh:
>> Since we are nearing the 5.1.0 release, I want to get an idea of what
>> major merges are ready to go once 5.1 is branched. I know Jon's netlist
>> code is ready to merge and I'm pretty sure
Hi,
On 21.02.19 21:21, Wayne Stambaugh wrote:
> Please let me know what
> you have in the queue so I can get an idea of how we should proceed with
> the merges.
I have a few refactoring branches that add "const", "constexpr",
"noexcept" and smart pointers to various places. These are mostly
pe 22. helmik. 2019 klo 5.17 Seth Hillbrand (s...@hillbrand.org) kirjoitti:
>
> Once v6 is started, I'd like to freeze the v5 parsers and make a copy of
> the parsers for v6. This would mean that all new format features would
> be implemented in a separate parser while any changes to underlying
Le 21/02/2019 à 21:21, Wayne Stambaugh a écrit :
> Since we are nearing the 5.1.0 release, I want to get an idea of what
> major merges are ready to go once 5.1 is branched. I know Jon's netlist
> code is ready to merge and I'm pretty sure that should be the first big
> merge. Does anyone else
Am 2019-02-21 15:21, schrieb Wayne Stambaugh:
Since we are nearing the 5.1.0 release, I want to get an idea of what
major merges are ready to go once 5.1 is branched. I know Jon's
netlist
code is ready to merge and I'm pretty sure that should be the first big
merge. Does anyone else have any
I have a patch for treating track clearance the same as track width. The
user can already specify a track width that is an exception to the
netclass width, and now do the same for clearance. (
https://youtu.be/05vfAvYwDio )
It's bitrotted for a year so I'd want an Ok before putting in the
I just have the net-name-escaping stuff so that all characters can be used in
labels, etc.
(Well, a couple of bug fixes too, but real minor stuff.)
> On 21 Feb 2019, at 13:21, Wayne Stambaugh wrote:
>
> Since we are nearing the 5.1.0 release, I want to get an idea of what
> major merges are
Since we are nearing the 5.1.0 release, I want to get an idea of what
major merges are ready to go once 5.1 is branched. I know Jon's netlist
code is ready to merge and I'm pretty sure that should be the first big
merge. Does anyone else have any major changes they want to merge as
soon as v6
24 matches
Mail list logo
