Mailing list archives : pcb-rnd

Date:Sat, 28 May 2022 08:26:20 +0200 (CEST)
Subject:[pcb-rnd] project state update: 2022 roadmap
replies: 5678 from John Griessen <>
Hi all,
I am sharing my plans for the rest of 2022 and early 2023 on Ringdove. 
This includes some strategic decisions and their rationale. 
None of these would affect daily use of pcb-rnd, camv-rnd, sch-rnd, so 
it's safe to skip this mail.
Read on if you are interested in where the whole Ringdove project is 
heading, where each subproject is heading and how I decided about the 
0. TL;DR: roadmap on calendar
Jun   sch-rnd alpha
Jul   sch-rnd alpha, librnd 3.2.0
Aug   sch-rnd alpha
Sep   sch-rnd 0.9.0 (beta!)
Oct   focusing on miniboxtk
Nov   focusing on miniboxtk
Dec   focusing on librnd4.0.0 + miniboxtk HID (the "SDL HID")
Jan   release of librnd4.0.0
Mar   hopefully release of sch-rnd 1.0.0
1. Now: sch-rnd, pcb-rnd
sch-rnd develipemnt is going fast. In fact I estimate we are about 2 
months ahead of schedule at the moment. (We could go even 
faster, bottleneck is coordinated user testing.)
So we are going to have an sch-rnd beta release, usable for the PCB 
workflow with pcb-rnd maybe even in September.
For ringdove, the big releases of 2022 will be that sch-rnd beta and 
librnd 3.2.0. 
Meanwhile pcb-rnd is getting mainly bugfix maintenance, because I am 
concentrating my energies on sch-rnd and librnd. As I wrote earlier: 
pcb-rnd is somewhat mature so we have big new features less frequently and 
we have longer calm periods focusing only on bugfixes and minor 
improvements. 2022 is definitely such a calm period for pcb-rnd.
2. Now: librnd 3.2.0
We are reaching the half time mark at the initial sch-rnd (cschem) 
implementation project. As a side effect I am also working on librnd 
3.2.0, which implements the API extension requests I kept accumulating 
while working on sch-rnd. It's because librnd started its life within 
pcb-rnd, so it offered the API needed for pcb-rnd. But I knew I wanted to 
use the same API for the rest of Ringdove. So I separated librnd within 
pcb-rnd the moved it out. But back then the only user was pcb-rnd, so all 
the generalization for other apps were provisions. Then I started to use 
it for camv-rnd, and it mostly worked. 
But camv-rnd is a small application in all regards. When I started intense 
work on sch-rnd, an application that is comparable to pcb-rnd in 
complexity, I started to see where librnd API needed a bit more 
flexibility, more generalization. No big things: the overall design works 
well, these are mostly little details, corner cases or minor features 
pcb-rnd never had or needed but sch-rnd does.
So I kept these accumulating until the current cycle, so I can add them 
all and bump the middle version number and get librnd 3.2.0 with the next 
Meanwhile there is a parallel bag of accumulated change requests for 
librnd 4.0.0, for the same reason. You can look at it in librnd's TODO, in 
svn trunk/doc/TODO or online:
These are changes that would break API, thus they can not be done in 
librnd 3.x.x. Half of them are cleanups, removing obsolete API currently 
kept only for backward compatibility (so that latest librnd 3.x.x works 
with oldest pcb-rnd that required librnd 3.0.0).
3. sch-rnd after the beta
So what's after sch-rnd beta?
For sch-rnd, releasing the beta means I should stop intense development 
for a while and give time for users to test what we already have, and try 
to get those features debugged and fixed so that the first stable release 
can be done. I expect that stable release to happen in the first 
third of 2023, after a series of 0.9.x beta releases from last third of 
4. The next big thing: librnd 4.0.0 (and miniboxtk)
If you look at it from my time allocation's point of view: pcb-rnd is 
on low power maintenance mode, camv-rnd is in an even lower power 
"pretty much finished" mode and from around September sch-rnd goes in low 
power "let's test and fix existing stuff before adding more" mode.
Which means I will  get bored^W^W have more time to do long term, 
strategic, background stuff.
You may remember our current Big Three on the pcb-rnd side were: poly lib 
rewrite, SDL HID, grbs routing a.k.a. push-and-shove. When I last wrote a 
similar project update, I was not yet sure which one I was going to work 
on in the next free period.
I managed to decide, and it will be the "SDL HID", or rather, miniboxtk.
I will need to roll librnd 4.0.0 before the first stable release of 
sch-rnd. It's because some of the new features in sch-rnd, especially 
multi-sheet support (that pcb-rnd and camv-rnd currently don't have) 
requires more drastic API changes.
The librnd 4.0.0 swithcover will be big, as the whole point of incrasing 
the first verison number is that we won't be compatible with 3.x.x, which 
means I will also need to upgrade pcb-rnd, camv-rnd and sch-rnd.
I want to do this from early December to mid/late January. Rationale: 
looking back to the past many years of pcb-rnd, the yearly user activity 
has a low peak in December and January. So doing such a big switchover 
in that period will cause the least trouble to users who are working from 
svn directly.
Of course after all the switchover the "collecting breaking API change 
requests for 5.0.0" will start, because I am sure there will be new 
features and user requests in the apps that will lead to figuring how some 
existing librnd APIs need to be extended. But then for some time, 
hopefully for years I won't need to actually do 5.0.0.
The big risk is that I miss something important from 4.0.0 and then it 
either blocks some aspects of the Ringdove project or forces me to do an 
5.0.0 earlier. There are two hot areas where such missed API upgrades 
could be found: new Ringdove apps and GUI HIDs. 
After sch-rnd I don't expect new Ringdove apps of this scale for a while. 
However, on the GUI side, we'll need to move: lesstif is getting less and 
less usable and maintenance cost is too high. We really need to replace it 
with something that's as portable (especially to old UNIX) but has simpler 
internals. So far we have only two working GUI HID families: lesstif and 
gtk. The librnd4 API risk is that if we start working on a 3rd GUI HID 
family after librnd4 and we figure something in the HID API needs to be 
done differently, we can't change it anymore until 5.0.0. 
Thus having a workign prototype of a 3rd HID API family before releasing 
librnd 4.0.0 is important.
5. miniboxtk
This 3rd family would be with my project miniboxtk, which is SDL-only at 
the moment. 
I originally though it would be SDL-only forever. But then I tried to 
implement widgets in lesstif and figured how unreasonably complex the 
internal APIs are. So I've changed my mind about miniboxtk.
I will go and split it up into a frontend and a backend. The frontend will 
be the API and all internal mechanisms (widgets, screen estate allocation, 
etc) and the backend will be how this gets to the GUI (e.g. using SDL). 
Besides SDL I will also implement a raw xlib backend. 
This sounds redundant first, as SDL works on X too. But SDL is rather huge 
and does a lot more than just GUI and is not pure C89. Which means it 
would be challenging to compile it on an old UNIX system. Normally I would 
say who cares, we have lesstif for that, but I think on the long run it 
will be cheaper to maintain an xlib backend in miniboxtk than maintaining 
the lesstif HID. 
So the plan is: I would start working on miniboxtk from this summer, 
especially after the first beta release of sch-rnd. Then by december, when 
I would start working on librnd 4.0.0, I would already have enough API so 
I could write a librnd HID for miniboxtk. It probably wouldn't result in a 
full working API at the moment librnd 4.0.0 is released, only a few 
releases later, but at least it would ensure we have enough API upgrades 
in 4.0.0.
As a side effect this also saves us from gtk long term. Which means I will 
keep on supporting our gtk2 and gtk4 HID, but we won't necessarily have to 
deal with gtk5/gtk6/gtkN later.
Best regards,

Reply subtree:
5675 [pcb-rnd] project state update: 2022 roadmap from
  5678 Re: [pcb-rnd] project state update: 2022 roadmap from John Griessen <>
    5679 Re: [pcb-rnd] project state update: 2022 roadmap from
      5680 Re: [pcb-rnd] project state update: 2022 roadmap from John Griessen <>