| ID: | 5675 |
| From: | rn...@igor2.repo.hu |
| Date: | Sat, 28 May 2022 08:26:20 +0200 (CEST) |
| Subject: | [pcb-rnd] project state update: 2022 roadmap |
| replies: | 5678 from John Griessen <jo...@cibolo.com> |
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 directions. 0. TL;DR: roadmap on calendar (2022) 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") (2023) Jan release of librnd4.0.0 Feb 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 release. 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: http://repo.hu/cgi-bin/minisvn.cgi?cmd=cat&repo=librnd&path=trunk/doc/TODO 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 2022. 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. Rationale: 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, Igor2
Reply subtree:
5675 [pcb-rnd] project state update: 2022 roadmap from rn...@igor2.repo.hu
5678 Re: [pcb-rnd] project state update: 2022 roadmap from John Griessen <jo...@cibolo.com>
5679 Re: [pcb-rnd] project state update: 2022 roadmap from rn...@igor2.repo.hu
5680 Re: [pcb-rnd] project state update: 2022 roadmap from John Griessen <jo...@cibolo.com>