Release 0.0.20 checklist

[guitorri]

• Branch release-0.0.20
• Update NEWS.md
• Update strings/ push to transifex / warn translators / pull update
• Produce release candidate, merge to master, tag and -rc1, make and distribute tar-ball
• Tag to https://github.com/Qucs/qucs-help
• Merge release- into master and develop.
• Tag qucs-0.0.20 into master.
• Move the base of all PRs to develop
• Delete release-0.0.20
• Sync master branch on SF repository one last time...
• Produce source packages, upload to SF
• Produce Windows and macOS packages, upload to SF
• Update website, landing and download pages
• Announce qucs-devel, qucs-help, update SF news
• Update Wikipedia

[andresmmera]

@guitorri, @felix-salfelder there are a few PRs already tested and ready to be merged like #769, #770, #767 and maybe #448 (I didn't check this latter). What should we do with these PRs? Should we merge them in develop in the short term (next week or so) or just wait until the new Qucs release?

[felix-salfelder]

#769, #770 look right to me. (the others don't)

i can't test them now. too much on the table.. otherwise i think they could go to develop, either way.

[guitorri]

@andresmmera I tagged two of the issues to 0.0.21.
Once reviewed, feel free to merge into develop.

[Rmano]

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..).

[andresmmera]

I agree with Romano, qucs v20 looks much better than 0.0.20 :-)

[guitorri]

We should use semantic versioning to correctly convey the development status. https://semver.org/
If we adhere to that the numbers will quickly grow to whatever they need to be.
This requires more planing and communication among developers.

[in3otd]

convey the development status

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.
That's to say that we should be well past version 1.0.0 since a long time already...

And by the way, we should probably remove Status: Alpha from the SourceForge page.

more planning and communication among developers

add also "more developers" to that

[Rmano]

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).

[felix-salfelder]

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.

[Rmano]

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

[guitorri]

The qucs-0.0.20-rc1 version is merged and tagged on the master branch.
The configured tarball will be shortly available at: https://sourceforge.net/projects/qucs/files/qucs/0.0.20/

[Vort]

Do test Windows binaries exists for -rc version? I want to check if certain bug from 0.0.19 is fixed.

[in3otd]

These links point to the latest Qucs binary packages for Windows, automatically built by AppVeyor from the master branch:

• 64-bit version
• 32-bit version

so they currently contain the binaries for the 0.0.20 release candidate.

[rjordans]

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.