Release 0.0.20 checklist #822
Comments
|
@andresmmera I tagged two of the issues to 0.0.21. |
|
First of all, 1000+ thanks to all the developers of QUCS. I am using it since, well, forever and it does what it says; at least analog simulations rocks, especially under didactic/education point of view, and the application is way prettier than, say, LTspice. To the point: shouldn't be the right time to remove that two "0.0." in front of the release? I've used way worst app claiming 4.0... I think that a 1.0 is overdue, or maybe a Mozilla-like versioning (qucs v20, v21 etc..). |
|
I agree with Romano, qucs v20 looks much better than 0.0.20 :-) |
|
We should use semantic versioning to correctly convey the development status. https://semver.org/ |
well, as already pointed out elsewhere, the semver page seems more oriented about versioning libraries. I mean, for an application versioning should be more related to user-visible changes, IMHO. E.g. if after refactoring all the code the appearance and functionality remains the same that would just be a patch version increase. And by the way, we should probably remove
add also "more developers" to that |
|
After more than two years using QUCS in my day-to-day teaching at a University, where it has been greatly useful and has churned happily almost anything I threw at it, I feel I have to formally ask the Developers (yes, capital D) to rethink the release number. I know it's true that a rose with any other name will smell the same, but names do matter. A release 0.0.20 conveys the idea of a super-alpha software with a lot of bugs and barely usable, which QUCS is not. Yes, it has some rough edge (who hasn't?) and it could be better (who couldn't?), but it's no more a child. It has grown up, it's able to fly mostly well, and I think that the version should convey this. Developers, you did a great thing (and are still doing it). Take the plunge and do yourself a gift (it's the season!) and call it 1.0 (or 0.9 if you want --- but I fill that most of the enhancements you are working on sound more like a "wow, multi-sim core, that's 2.0" thing). Just my 2 cents, but a lot of people feels that QUCS, like the rose, deserves a better "name" (version). |
|
On Sat, Dec 15, 2018 at 12:40:13AM -0800, Romano Giannetti wrote:
Just my 2 cents, but a lot of people feels that QUCS, like the rose, deserves a better "name" (version).
Thanks for your cents and for keeping up the discussion. I was not aware
of this "thread".
How about simply changing 0.0.20 to 0.1.0? This change will be hard to
object to (anybody?). Further, it is quite easy to implement, and has no
weird side effects downstream, e.g. in packageing.
A change in the versioning scheme (e.g. v1.0, 1.0 etc) is a bit over the
top. It adds work without any benefit, as opposed to, say, thinking
about file format or API versioning.
That leaves a jump 0.0.19 to 1.0.0. It violates the principle of least
surprise, so I advise against doing that.
|
|
The important thing is, IMHO, removing the double 0 at the start, that normally means that the SW is just alpha/unstable try. What I feel right would be to switch to 0.9, and then going 1.0 when the (not so big) list of bug-type issues is fixed. There is a very notable precedent... when Linux kernel jumped to 0.9 in 1992. Being there... |
|
The |
|
Do test Windows binaries exists for -rc version? I want to check if certain bug from 0.0.19 is fixed. |
|
These links point to the latest Qucs binary packages for Windows, automatically built by AppVeyor from the master branch: so they currently contain the binaries for the 0.0.20 release candidate. |
|
Hey all, thanks for working on this! I've been using Qucs quite a bit lately and am loving it. Regarding the 0.0.20 version, do you have an idea yet on the timeline towards the official release? I've been playing around with the -rc version lately and haven't found issues so far. |
|
I am back from vacations. I will make the release in a few days. |
|
@guitorri ...think about that release number... 😉 |
|
Sorry @Rmano , I will not change the release number at this time. |
|
@guitorri I supposed it, it was just a bit of wishful thinking... but please consider, after this release, to change it so that QUCS seems the polished product that it is. There are several commercial 1.0+ things that are really worst... |
|
Sorry for the delay, I had a lot of things going on these days. |
|
Qucs 0.0.20-rc2 is tagged and the tarbals are available at: I noticed I forgot to update the news/changelog... will do for the release. |
|
I am struggling a bit to build the Windows binaries. Things changed on the build system and the official Qt4.8.7 is no longer being configured properly. Working on it... |
|
I tried again to build the Windows binaries. Not going well. QTDIR needs to be used because pkgconfig is not available with official Qt4.8. QTDIR should still work after pkgconfig was introduced, but it doesn't. To debug the situation I need to bootstrap on the host. I tried with Windows/MSYS/mingw/qt4 combination as done for the last binary. However MSYS has an old version of automake and it is failing to bootstrap. I tried cross-compiling with Wine but the bootstraping takes too long and so far I didn't manage to make QTDIR work again. The whole point of doing this way is that gcc needs to be shipped to enable free-hdl and the verilog-a features. |
|
drop windows support |
|
well, of course that would not be fair to our Windows users - which not surprisingly seem to be the vast majority (well above 90 %, judging from the Sourceforge download stats). @guitorri not sure I understood what the problem is; what's the main difference between the release binary you are trying to do and the AppVeyor build? |
Is CMake build system operational for Qucs now? You can try to use CMake. It should work on Wine without MSYS2. |
Actually the percentage of Windows users is not 90%, because Sourceforge cannot count installations from repositories. The most of Linux users installing Qucs using repositories, not a Sourceforge. |
|
@in3otd, the issue is that Freehd and the Verilog-A dynamic loader require a C++ compiler. @ra3xdh, Yes CMake should be working. I was thinking about trying with CMake, did not have the time so far. Hopefully this week... We could simply drop the dependencies and ship the binary from Appveyor and tell people to install MSYS2? If they want those features? |
|
My opinion is going with @guitorri idea. The loss of Freehdl and Verilog-a is minor compared to the unavailability of a Windows version (I, for example, use QUCS in several classes, and my University's Labs OS is Windows --- can't change it). It should be spelled out in the program when trying to use it in the Windows version, of course, so that users know what happens. I would like to help, although my C++ is too rusty --- count with me for testing binaries, on the other hand. |
|
Is manually updating |
|
I already wasted too much lifetime messing with build systems. If you want to try, be my guest. Lets try to merge #953, #951 and #946 and release. For Windows we take the package from AppVeyor (ASCO already included), manually add qucs-docs, qucs.ba, freehdl (one last time) and link to Mingw 4.8.2 compiler (needed to run freehdl) on the readme and zip the package as in 0.0.19 |
|
I tried cross-compiling via Wine, got to the point where it will try to use |
|
FYI, I've |
|
I just pushed a |
|
Nice. I just updated macports version to 0.0.20-rc2 and waiting for the final release. Thank you very much for your work! |
|
Hi guys. |
|
Hi buenoshun.
Thanks for your interest. I only have an incomplete answer, but maybe
others can give more detail.
On Fri, Jul 09, 2021 at 06:30:02AM -0700, buenoshun wrote:
This last post is from 2021? The conversation seem to have stopped here about a year ago.
As far as I know, the focus has shifted from "release 0.0.20" to "move
to Qt>4" and then to implementing "modular Qucs".
When can we expect the 0.020 windows binary ?
Qucs 0.0.20 has not been released yet. You could try 0.0.20-rc2.
The 0.020 has a new feature that I happen to need, the de-embedding
s-parameter model (inverse matrix).
To my knowledge, de-embedding is a Qucsator feature. There is a
standalone Qucsator package now, and a 0.0.20 release. It does not
depend on Qt and may be easier to build.
|
|
Hi Felix, |
|
On Fri, Jul 09, 2021 at 10:36:09AM -0700, buenoshun wrote:
What is qucsator ? I have been using regular QUCS gui on windows for over a decade.
Qucsator is a program that simulates electrical networks. It has been
added to Qucs on 2003-12-21.
It seems this qucsator package is not a windows binary, neither a GUI.
Correct.
I cannot build/compile software.
There should be instructions enclosed. Some operating systems and their
users ship or provide or support readily compiled software packages or
build rules for non-developers e.g. [1].
[1] https://aur.archlinux.org/packages/?O=0&K=qucs
|
|
Hi Felix, I would like to help a bit with the qucs roadmap. My c(++) programming is still a bit rusty though. Could you point me to some smaller task, that I could work on? |
|
On Fri, Jul 16, 2021 at 11:06:21AM -0700, Carsten Kögler wrote:
I would like to help a bit with the qucs roadmap. My c(++) programming
is still a bit rusty though. Could you point me to some smaller task,
that I could work on?
Thanks for your interest. Recently arch users [1] have reported a crash
that needs fixing [2]. I believe that this is worth doing, as any future
qucs will likely run qucsator.
Qucsator has few more bugs of less severity. I don't have a favourite.
Perhaps it would be nice to include the regression tests from qucs-test,
for convenience.
Beyond that, and off topic, I tend to work on modular Qucs these days.
Importing or activating more tests (also from qucs-test) may be a
starting point, and needs doing. Other stuff quickly becomes less small.
[1] https://aur.archlinux.org/packages/qucs/
[2] Qucs/qucsator#29
|
|
0.0.20 is tagged and archived. Thanks to all who tried. |
release-0.0.20-rc1, make and distribute tar-ballrelease-intomasteranddevelop.qucs-0.0.20intomaster.developrelease-0.0.20The text was updated successfully, but these errors were encountered: