Misunderstanding developer previews versus release candidates
andrew at ctech.me
Thu Nov 7 12:40:50 EST 2013
> The way the rest of the world works is
That's a pretty generalized assumption. Release processes and version
naming varies pretty wildly depending on how often you iterate and what
goes into each iteration.
Most of my applications (i'm an in-house development shop working on
internal applications for a farm services company) get small updates
weekly, daily, or sometimes even several times in a day between hot fixes
and urgently needed features/additions. As a result the only way I could
keep track of anything was base my version numbers off the date it was put
out there. For example: an update released today to a specific application
would be 13.11.7 and if I have to hotfix a feature that was added in a
hurry on the same day I add a 4th number to increment. 184.108.40.206 etc. The
first number being the year the second being the month and the third for
the day and the optional 4th being the number of the release for that day.
It doesn't make any sense to developers in a different situation than I am
in but its the only way I have found that releasing as frequently as I do
can be managed sanely.
I think run-revs new release process/version numbers makes way more sense
than it used to in pre-open-source-days.
On Thu, Nov 7, 2013 at 11:20 AM, Mark Wieder <mwieder at ahsoftware.net> wrote:
> Thursday, November 7, 2013, 6:36:56 AM, you wrote:
> > Our release process is simple and pragmatic.
> Thanks. The way the rest of the world works is
> initial design
> in development : alpha
> feature complete : beta
> code complete : release candidate
> golden master
> -Mark Wieder
> ahsoftware at gmail.com
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
andrew at ctech.me
More information about the Use-livecode