kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #01681
Re: Versioning
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"Richard A Burton" <richardaburton@...>
-
Date:
Sat, 30 Aug 2008 10:28:24 +0100
-
In-reply-to:
<200808301050.17287.diemer@...>
2008/8/30 Jonas Diemer <diemer@...>:
> That's exactly my point too. There needs to be a marker saying "this version
> is considered stable and can be used for production use". So how about
There is a marker. The marker is that it gets released. Nightly builds
may be made available, but only the official releases go on the
official site. If it's there (and isn't marked as a release candidate
of course) then it's a proper release and considered good for
production use.
> adding
> a "traditional" version number to the release date whenever such a release
> is
> considered stable, i.e.
In my experience, working at a major software company, marketing
drives the version numbers. Yes, there are new feature in each (also
driven by marketing of course), but making it a major release or a dot
release, or even just a service release depends on what you are trying
to achieve with the release, how you license upgrades, how you want it
to fit into a larger portfolio. None of this matters for Kicad. I
can't see what you are trying to achieve by changing the numbering
scheme. Aside from making it clear that's it's a production ready
release (point already covered above), what else does it provide? As
I've said the versioning doesn't really tell you much in terms of the
actual release, how much changes between different types of release
varies from project to project.
I checked in a couple of changes yesterday/day before that can improve
things slightly. Including a way to keep the real program version
(currently date type) along with having the actual svn date and
revision in the about dialog, and a script that can be used to build a
source tar with the appropriate svn info in it (which can be used to
make the official source available on sourceforge). This will allow
anyone building from source to be sure they have proper milestones
(i.e. not having to go to svn and risk building head, or finding what
revision needs to be checked out), and the proper versioning to be
displayed in the build to prove this and help with any debugging.
Richard.
Follow ups
References