Version Numbering

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Version Numbering

ChrisGood
> Date: Sat, 21 Mar 2015 21:17:50 +0900

> From: John Ralls <[hidden email]>
> To: Geert Janssens <[hidden email]>
> Cc: [hidden email], Chris Good <[hidden email]>
> Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods
> to Advanced Portfolio Rpt
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> > On Mar 21, 2015, at 3:57 PM, Geert Janssens
> <[hidden email]> wrote:
> >
> > Technically that is correct.
> >
> > However the unstable releases are not the focus of development. They are
> only pre-releases
> > intended for testing. They all eventually lead up to a "major/minor
release"
> in the next stable
> > series. And that release is the relevant one, not the unstable releases.
> >
> > So I think you can mention unstable releases, yet explain that
git-master
> will lead up to the
> > next "major/minor release" or stable release series.
> >
> > You'll note that I keep adding "major" as I really have issues with
calling

> these big updates
> > "minor". Perhaps we can have a brainstorm over this among developers
> and interested
> > commmunity members.
>
> Yeah, I agree. Major releases are when the middle number changes and
> minor releases are when the 3rd number changes. Minor releases are by
> policy bug-fix only. (That should be in the wiki along with the numbering
> system). The first number changes only when we make huge architectural
> changes: The last one, from 1 to 2 involved changing most of the code from
> Scheme to C *and* upgrading the GUI from Gtk1 to Gtk2. I think completing
> the C++ rewrite of the engine including making it SQL query driven instead
of
> all in memory will merit a first-number change to 3, but I'm not going to
> promise that that will be done by 2017 so there will probably be a 2.8
series
> before we're ready for 3.0. If we subsequently change the GUI that might
> warrant another first-number change. But what's a good name for first-
> number releases? "Catastrophic" is probably correct, but isn't really an
image
> we want to project for user recruitment. "Enormous", "Earth-shaking", and
> so on sound silly. How about "!
>  Global" or "Fundamental" to indicate that the way the program works is
> different from before?
>
> Regards,
> John Ralls
>

Thanks for picking up my 'faux pas' re odd/even numbering (temporary brain
fade I hope).

I've done a little research on version numbering best practices.
http://en.wikipedia.org/wiki/Software_versioning is quite interesting.

Some of the commonly used version numbering schemes include:

Major.Minor.[buildno|bugfix|revision|patch]
Framework.Major.Minor

I totally agree with Geert that the 2nd level should be Major, not Minor.
John mentioned 'architectural changes' and I quite like
Architecture.Major.Minor although I prefer Framework.Major.Minor.

What does everybody think?

http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_read_my_
old_data_file.3F talks about major/minor and stable/unstable without really
defining them.

John, I agree defining our version numbering terminology should be done in
Development Process wiki.
(note to myself: add a link to there from the FAQ wiki.)

Regards,

Chris Good

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

John Ralls-2

> On Mar 22, 2015, at 9:51 AM, Chris Good <[hidden email]> wrote:
>
>> Date: Sat, 21 Mar 2015 21:17:50 +0900
>> From: John Ralls <[hidden email]>
>> To: Geert Janssens <[hidden email]>
>> Cc: [hidden email], Chris Good <[hidden email]>
>> Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods
>> to Advanced Portfolio Rpt
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=us-ascii
>>
>>> On Mar 21, 2015, at 3:57 PM, Geert Janssens
>> <[hidden email]> wrote:
>>>
>>> Technically that is correct.
>>>
>>> However the unstable releases are not the focus of development. They are
>> only pre-releases
>>> intended for testing. They all eventually lead up to a "major/minor
> release"
>> in the next stable
>>> series. And that release is the relevant one, not the unstable releases.
>>>
>>> So I think you can mention unstable releases, yet explain that
> git-master
>> will lead up to the
>>> next "major/minor release" or stable release series.
>>>
>>> You'll note that I keep adding "major" as I really have issues with
> calling
>> these big updates
>>> "minor". Perhaps we can have a brainstorm over this among developers
>> and interested
>>> commmunity members.
>>
>> Yeah, I agree. Major releases are when the middle number changes and
>> minor releases are when the 3rd number changes. Minor releases are by
>> policy bug-fix only. (That should be in the wiki along with the numbering
>> system). The first number changes only when we make huge architectural
>> changes: The last one, from 1 to 2 involved changing most of the code from
>> Scheme to C *and* upgrading the GUI from Gtk1 to Gtk2. I think completing
>> the C++ rewrite of the engine including making it SQL query driven instead
> of
>> all in memory will merit a first-number change to 3, but I'm not going to
>> promise that that will be done by 2017 so there will probably be a 2.8
> series
>> before we're ready for 3.0. If we subsequently change the GUI that might
>> warrant another first-number change. But what's a good name for first-
>> number releases? "Catastrophic" is probably correct, but isn't really an
> image
>> we want to project for user recruitment. "Enormous", "Earth-shaking", and
>> so on sound silly. How about "!
>> Global" or "Fundamental" to indicate that the way the program works is
>> different from before?
>>
>> Regards,
>> John Ralls
>>
>
> Thanks for picking up my 'faux pas' re odd/even numbering (temporary brain
> fade I hope).
>
> I've done a little research on version numbering best practices.
> http://en.wikipedia.org/wiki/Software_versioning is quite interesting.
>
> Some of the commonly used version numbering schemes include:
>
> Major.Minor.[buildno|bugfix|revision|patch]
> Framework.Major.Minor
>
> I totally agree with Geert that the 2nd level should be Major, not Minor.
> John mentioned 'architectural changes' and I quite like
> Architecture.Major.Minor although I prefer Framework.Major.Minor.
>
> What does everybody think?
>
> http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_read_my_
> old_data_file.3F talks about major/minor and stable/unstable without really
> defining them.
>
> John, I agree defining our version numbering terminology should be done in
> Development Process wiki.
> (note to myself: add a link to there from the FAQ wiki.)

I think "Framework" might be confusing. In general use it means a package of libraries, like a GUI framework of which Gtk is an example. Changing the GUI framework on which GnuCash is based would likely justify a first-number change, but there are other reasons too. Where did you find someone using that for "first-number" changes?

"Architecture" also has a bunch of special meanings in CS, but it does convey a more-major-than-major sense, but I'm not really any more enthusiastic about it than "Global" or "Fundamental".

As for the FAQ, it looks to me that the whole "Developing Gnucash: Source Code Overview" needs a rewrite, starting with the title: There's nothing resembling a Source Code Overview there.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

RE: Version Numbering

ChrisGood
> -----Original Message-----

> From: John Ralls [mailto:[hidden email]]

> Sent: Sunday, 22 March 2015 2:59 PM

> To: Chris Good

> Cc: [hidden email]

> Subject: Re: Version Numbering

>

>

> > On Mar 22, 2015, at 9:51 AM, Chris Good <
<mailto:[hidden email]> [hidden email]>

> wrote:

> >

> >> Date: Sat, 21 Mar 2015 21:17:50 +0900

> >> From: John Ralls < <mailto:[hidden email]> [hidden email]>

> >> To: Geert Janssens < <mailto:[hidden email]>
[hidden email]>

> >> Cc:  <mailto:[hidden email]> [hidden email],
Chris Good

> < <mailto:[hidden email]> [hidden email]>

> >> Subject: Re: [Bug 744918] Update Help Manual for Mike Alexanders mods

> >>       to Advanced Portfolio Rpt

> >> Message-ID: < <mailto:[hidden email]>
[hidden email]>

> >> Content-Type: text/plain; charset=us-ascii

> >>

> >>> On Mar 21, 2015, at 3:57 PM, Geert Janssens

> >> < <mailto:[hidden email]> [hidden email]>
wrote:

> >>>

> >>> Technically that is correct.

> >>>

> >>> However the unstable releases are not the focus of development. They

> >>> are

> >> only pre-releases

> >>> intended for testing. They all eventually lead up to a "major/minor

> > release"

> >> in the next stable

> >>> series. And that release is the relevant one, not the unstable
releases.

> >>>

> >>> So I think you can mention unstable releases, yet explain that

> > git-master

> >> will lead up to the

> >>> next "major/minor release" or stable release series.

> >>>

> >>> You'll note that I keep adding "major" as I really have issues with

> > calling

> >> these big updates

> >>> "minor". Perhaps we can have a brainstorm over this among developers

> >> and interested

> >>> commmunity members.

> >>

> >> Yeah, I agree. Major releases are when the middle number changes and

> >> minor releases are when the 3rd number changes. Minor releases are by

> >> policy bug-fix only. (That should be in the wiki along with the

> >> numbering system). The first number changes only when we make huge

> >> architectural

> >> changes: The last one, from 1 to 2 involved changing most of the code

> >> from Scheme to C *and* upgrading the GUI from Gtk1 to Gtk2. I think

> >> completing the C++ rewrite of the engine including making it SQL

> >> query driven instead

> > of

> >> all in memory will merit a first-number change to 3, but I'm not

> >> going to promise that that will be done by 2017 so there will

> >> probably be a 2.8

> > series

> >> before we're ready for 3.0. If we subsequently change the GUI that

> >> might warrant another first-number change. But what's a good name for

> >> first- number releases? "Catastrophic" is probably correct, but isn't

> >> really an

> > image

> >> we want to project for user recruitment. "Enormous", "Earth-shaking",

> >> and so on sound silly. How about "!

> >> Global" or "Fundamental" to indicate that the way the program works

> >> is different from before?

> >>

> >> Regards,

> >> John Ralls

> >>

> >

> > Thanks for picking up my 'faux pas' re odd/even numbering (temporary

> > brain fade I hope).

> >

> > I've done a little research on version numbering best practices.

> >  <http://en.wikipedia.org/wiki/Software_versioning>
http://en.wikipedia.org/wiki/Software_versioning is quite interesting.

> >

> > Some of the commonly used version numbering schemes include:

> >

> > Major.Minor.[buildno|bugfix|revision|patch]

> > Framework.Major.Minor

> >

> > I totally agree with Geert that the 2nd level should be Major, not
Minor.

> > John mentioned 'architectural changes' and I quite like

> > Architecture.Major.Minor although I prefer Framework.Major.Minor.

> >

> > What does everybody think?

> >

> >

>  <http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_re>
http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_r

 <http://wiki.gnucash.org/wiki/FAQ#Q:_Can_a_new_GnuCash_release_still_re> >
e

> > ad_my_ old_data_file.3F talks about major/minor and stable/unstable

> > without really defining them.

> >

> > John, I agree defining our version numbering terminology should be

> > done in Development Process wiki.

> > (note to myself: add a link to there from the FAQ wiki.)

>

> I think "Framework" might be confusing. In general use it means a package
of

> libraries, like a GUI framework of which Gtk is an example. Changing the
GUI

> framework on which GnuCash is based would likely justify a first-number

> change, but there are other reasons too. Where did you find someone using

> that for "first-number" changes?

>

> "Architecture" also has a bunch of special meanings in CS, but it does
convey

> a more-major-than-major sense, but I'm not really any more enthusiastic

> about it than "Global" or "Fundamental".

>

> As for the FAQ, it looks to me that the whole "Developing Gnucash: Source

> Code Overview" needs a rewrite, starting with the title: There's nothing

> resembling a Source Code Overview there.

>

> Regards,

> John Ralls

 

Hi John,

 

I'm not sure where I got the idea for "framework" as "first-number". I
cannot find anything about it now. I probably just saw it on the wiki
<http://en.wikipedia.org/wiki/Software_versioning> Software_versioning page,
not specifically as part of a version numbering system, and liked it more
than architecture as architecture has hardware/OS connotations to me. I
shouldn't have put it under 'commonly used version numbering schemes'.

Architecture is also just something I thought would be acceptable for the
"first-number".

 

Framework does have package libraries connotations that may rule it out. I'd
be OK with framework, but your "Global" or "Fundamental" suggestions
certainly have fewer connotations so may be better.

 

Regards,

 

Chris Good


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Christian Stimming-4
In reply to this post by ChrisGood
Dear Chris,

thanks for bringing up this question. In fact there are different views on
this topic around. I consider the version number as part of our marketing
communication to potential users. As such, the first-most number of our
software should represent something that is meaningful to the users. And it
should change as soon as something major that is meaningful to the users is
changed.

I've simply seen enough users who can't tell whether there is a version 2.2 or
2.4 or 22 or 24 or whatever of gnucash on their computer. They could for sure
tell whether they have version 2-something or 3-something. But the next number
is just magnitudes less important. Hence, we should use the important part of
the version number as our product marketing in a useful way.

Because of this, I am against the idea that we have to stick to the first
number "2" unless we have a major architectural change or some other whatever
major technological yadda yadda change inside gnucash. Instead, from my point
of view we should consider incrementing our first version number from 2 to 3
at some not-too-distant point in the future, as soon as this number change
would represent something useful for the user. For example, a gnucash version
that is multi-user-enabled would be enough of a reason to call that "version
3.something". Note that I don't care at all which technology was used to
achieve this feature.

Thing is, we can expect all users to tell whether their gnucash version number
starts with 2 or 3. But the number after that is already something that can be
remembered by only a minority of the users. Why should we easily let go of the
powerful communication tool to tell whether someone has a newer or older
version of the software? Instead, IMHO we should keep in mind to switch to
version 3.x within the next 1-3 years, as soon as we have enough user-visible
to justify this change.

Regards,

Christian

Am Sonntag, 22. März 2015, 11:51:57 schrieb Chris Good:

> > we want to project for user recruitment. "Enormous", "Earth-shaking", and
> > so on sound silly. How about "!
> >
> >  Global" or "Fundamental" to indicate that the way the program works is
> >
> > different from before?
> >
> > Regards,
> > John Ralls
>
> Thanks for picking up my 'faux pas' re odd/even numbering (temporary brain
> fade I hope).
>
> I've done a little research on version numbering best practices.
> http://en.wikipedia.org/wiki/Software_versioning is quite interesting.
>
> Some of the commonly used version numbering schemes include:
>
> Major.Minor.[buildno|bugfix|revision|patch]
> Framework.Major.Minor
>
> I totally agree with Geert that the 2nd level should be Major, not Minor.
> John mentioned 'architectural changes' and I quite like
> Architecture.Major.Minor although I prefer Framework.Major.Minor.
>
> What does everybody think?


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

John Ralls-2

> On Mar 23, 2015, at 6:41 AM, Christian Stimming <[hidden email]> wrote:
>
> Dear Chris,
>
> thanks for bringing up this question. In fact there are different views on
> this topic around. I consider the version number as part of our marketing
> communication to potential users. As such, the first-most number of our
> software should represent something that is meaningful to the users. And it
> should change as soon as something major that is meaningful to the users is
> changed.
>
> I've simply seen enough users who can't tell whether there is a version 2.2 or
> 2.4 or 22 or 24 or whatever of gnucash on their computer. They could for sure
> tell whether they have version 2-something or 3-something. But the next number
> is just magnitudes less important. Hence, we should use the important part of
> the version number as our product marketing in a useful way.
>
> Because of this, I am against the idea that we have to stick to the first
> number "2" unless we have a major architectural change or some other whatever
> major technological yadda yadda change inside gnucash. Instead, from my point
> of view we should consider incrementing our first version number from 2 to 3
> at some not-too-distant point in the future, as soon as this number change
> would represent something useful for the user. For example, a gnucash version
> that is multi-user-enabled would be enough of a reason to call that "version
> 3.something". Note that I don't care at all which technology was used to
> achieve this feature.
>
> Thing is, we can expect all users to tell whether their gnucash version number
> starts with 2 or 3. But the number after that is already something that can be
> remembered by only a minority of the users. Why should we easily let go of the
> powerful communication tool to tell whether someone has a newer or older
> version of the software? Instead, IMHO we should keep in mind to switch to
> version 3.x within the next 1-3 years, as soon as we have enough user-visible
> to justify this change.

Christian,

Good point, but where do we draw the line? Do we follow Firefox and use only two numbers, so we have a new first-digit release every 3 years?

I don't think that there's any argument that multi-user justifies a new first-digit number, but I also think it's pretty optimistic to plan for it in the next major release. Unless you're advocating for the Firefox model (minus the every-few-months bit, we don't have the resources for that), what else do you think might justify a first-number change? Do you think that 2.6 should have been 3.0?

What about API breaks in the Scheme and Python bindings? Not something most users care about, but folks with custom scripts sure do. We've always said that we don't guarantee API stability between major versions, but we also promote the bindings pretty heavily.

I suspect that users care most about file compatibility. We've done pretty well on that through the 2.x series, but along with multi-user will come a shift from default XML to default SQL, and going forward from that we'll want to normalize the schema, especially to move stuff out of slots.

The two combined would be a useful guideline: first-number changes mean that you'll have to revisit your scripts or your database will be upgraded so that it's not readable by the previous version except the closeout release.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Jeff Kletsky-3
On 3/23/15 12:20 AM, John Ralls wrote:

> What about API breaks in the Scheme and Python bindings? Not something
> most users care about, but folks with custom scripts sure do. We've
> always said that we don't guarantee API stability between major
> versions, but we also promote the bindings pretty heavily.
>
> I suspect that users care most about file compatibility. We've done
> pretty well on that through the 2.x series, but along with multi-user
> will come a shift from default XML to default SQL, and going forward
> from that we'll want to normalize the schema, especially to move stuff
> out of slots.
>
> The two combined would be a useful guideline: first-number changes
> mean that you'll have to revisit your scripts or your database will be
> upgraded so that it's not readable by the previous version except the
> closeout release.


 From a consumer perspective, as well as speaking as a product manager
for enterprise software, I generally expect that (after the database
upgrade has run):

* Major version number release
     * Meaningful improvement in functionality
     * Database schema may have changed and *likely not* be even
readable by previous versions of software with the previous major
version number (even in last of prior major version's releases)
     * API may have changed extensively, and may not be backwards
compatible

* Minor version number release
     * Some improvement in functionality beyond bug fixes
     * Database schema may have changed and *may not* be read/write
compatible with previous versions of software with the same major/minor
version number.
     * API may have been extended and certain features may have been
deprecated (but still functional)

* "Point" release
     * Primarily bug fixes
     * Database schema may have changed, but still read/write compatible
with previous versions of the software with the same major/minor version
number.
     * API may have been extended and certain features may have been
deprecated (but still functional)

If a non-backwards-compatible database schema change is absolutely
required for a point release, I'd consider first making it a minor
release. If that wasn't appropriate, very clear messaging in the app
prior to running the database upgrade, along with prominent information
in the release notes would be my approach.



Going along with this are the usual tenants of using mission-critical
software:

* It is the user's responsibility to back-up data before upgrading
(though I don't object to a warning before running the database upgrade
triggers)

* It is the user's responsibility to test, evaluate, and consider the
impact of upgrading to a new major version to determine if it provides
benefits sufficient to outweigh unforeseen impact of changes in
functionality, database, API, and the like *prior* to committing
production data to the new version

* The user should be able to review release notes that clearly outline
any deprecations, removals or significant changes in functionality,
including API changes. These release notes ideally will indicate when a
change has been made to the database schema.

* The user should have confidence that software vendor has tested the
new versions against data loss, as well as unexpected regressions or
changes in behavior. Further, that the vendor will any bugs or
unexpected behavior should be addressed promptly.



As a consumer example, I never "expect" that if I upgrade an Android
application that I'll be able to restore a previous version of the app
and have it work with the database and other data from the newer version.



Personally, I'd rather more time go into the 3.x line utilizing the
database backing store to improve performance, than having to make sure
that "2.last" can somehow understand the new schema and revert it to XML
or what have you.

My 2 cents, or pence, at the moment...

Jeff
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Christian Stimming-4
In reply to this post by John Ralls-2
Am Montag, 23. März 2015, 09:20:56 schrieb John Ralls:

> > Instead,
> > from my point of view we should consider incrementing our first version
> > number from 2 to 3 at some not-too-distant point in the future, as soon
> > as this number change would represent something useful for the user. For
> > example, a gnucash version that is multi-user-enabled would be enough of
> > a reason to call that "version 3.something". Note that I don't care at
> > all which technology was used to achieve this feature.
>
> Good point, but where do we draw the line? Do we follow Firefox and use only
> two numbers, so we have a new first-digit release every 3 years?

John,

I also don't have a final answer to this question. The important point from me
is that we shouldn't be more shy than necessary w.r.t. increasing the first-
digit number. My criterion would be the vague "If something important changes
that is important to many users", and indeed that's rather vague and needs to
be revisited each time we start the next stable series.

In case of 2.4 -> 2.6: From what I recall there were no real "important change
for many users", so in that case increasing only the second digit was just
fine.

If next time we have the same situation - fine, let's go to 2.8.

But after that, I would suggest to be somewhat more reluctant to go to a two-
digit minor number, i.e. before switching to 2.10 we should rather switch to
3.0 even if the set of new feature is again in a similar range as it was in
the 2.4->2.6 switch. A two-digit minor number makes things more confusing than
necessary and I would rather like to avoid that. But that's a future
discussion and not today's topic.

Maybe the 2.2->2.4 switch had enough changes so that we could have gone to 3.0
instead. But that's long ago and just hypothetical.

Yes, the points you raise can give valid arguments: multi-user; file
compatibility; script API. To summarize, I think we do not have to draw clear
lines right now, but can live with a rather vague description of our policy,
and make the actual decisions about the numbering of the next stable series
right at the point when we know what will be in there.

Regards,

Christian

>
> I don't think that there's any argument that multi-user justifies a new
> first-digit number, but I also think it's pretty optimistic to plan for it
> in the next major release. Unless you're advocating for the Firefox model
> (minus the every-few-months bit, we don't have the resources for that),
> what else do you think might justify a first-number change? Do you think
> that 2.6 should have been 3.0?
>
> What about API breaks in the Scheme and Python bindings? Not something most
> users care about, but folks with custom scripts sure do. We've always said
> that we don't guarantee API stability between major versions, but we also
> promote the bindings pretty heavily.
>
> I suspect that users care most about file compatibility. We've done pretty
> well on that through the 2.x series, but along with multi-user will come a
> shift from default XML to default SQL, and going forward from that we'll
> want to normalize the schema, especially to move stuff out of slots.
>
> The two combined would be a useful guideline: first-number changes mean that
> you'll have to revisit your scripts or your database will be upgraded so
> that it's not readable by the previous version except the closeout release.
>
> Regards,
> John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

RE: Version Numbering

ChrisGood
Hi All,

I've asked for people to give their opinions on a GnuCash version numbering
system as, from my few small documentation contributions, I think this
should be defined somewhere.

I'll summarise what I've observed so far now that's it's been a week.

There has been some good input about what the 3 segments of the GnuCash
version number should be used for, although there is no general consensus
and some people are OK to leave the decision till later, or maybe decide if
the first 1 or 2 segments should change on a case by case basis.

We don't seem to be getting anywhere picking names for the 3 segments of the
version number, particularly the first segment.
We've had the following suggestions (in no particular order):

First Level:
        Major
        Architecture
        Global
        Fundamental
        Framework
        Basic
        Base (I'm throwing this into the ring here)
Second Level:
        Major
        Minor
Third Level:
        Minor
        Micro
        Bugfix
        Point
        Revision
        Patch

Have I missed any?

I think it is generally agreed, (from the small number of opinions
expressed so far), that level 2 should be Major and level 3 should be Minor.
Can everyone that has an opinion please let us know, particularly regarding
the level 1 name?

Regards,
Chris Good

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Version Numbering

David Raker
My input probably isn't very merited, since though I joined this list with
the intention of contributing,  I haven't actually found the time.
Nonetheless,  I do some development and systems administration for
clients,  and when discussing version numbers what I most commonly
encounter (and use on software I write) is as follows:

The first level is generally refered to as the major version,  the second
as the minor version. The third level is more variable,  but is usually
release, or sometimes patch or point.

If someone has not read your documentation or doesn't know otherwise,  that
is how they will most likely refer to versions,  and thus probably the most
rational to use.

As far as expectation of what the number implies,  I would generally assume
that a change in the first number indicates a change in major components
that is likely to affect compatibility. A change in the second number
indicates a lesser milestone,  perhaps with new features,  but may or may
not also break some compatibility.  Changes in the third number are often
bug fixes or other changes that should never break compatibility if at all
possible. Obviously the onus is on an administrator to do due diligence to
ascertain that this sort of assumption is true before updating things.

Preferably,  things which affect interoperability get added or deprecated
at changes in the minor number or above,  but only removed completely at
changes in the major version. While this might mean that in a client/server
environment,  for instance,  that a client versioned 2.4.x cannot use new
backend features from 2.6.x, it hopefully should not mean that client 2.4.x
cannot function with backend 2.6.x because something it requires is gone.
Rolling back the data storage layer to an old minor version might well
still be lossy, since new features are gone.  I wouldn't take bets on
whether client 2.6.x can use backend 2.4.x either,  since that probably
means it needs to constrain itself based on capabilities of the current
server.

With regard to the changes you have been discussing, I would normally
assume that a rewrite in a new language,  eg the move to c++, would be
accompanied by a major version change, but since I think that is going one
component at a time,  perhaps not. I would still try to keep changes that
introduce new dependencies or otherwise change build requirements at minor
version numbers. The multiuser functionality would merit at least a minor
version bump,  if it somehow came without a major change in architecture. I
would think the change from loading the whole data store into memory to a
system that reads and writes changes incrementally would be significant
enough for a major version, though, since that is a pretty big change in
the core architecture of the application.  Incompatibilities in
scripting/extension languages would also need at least a minor version
change,  and removal of a scripting/extension language should only happen
at a major version change.

Any way you do it,  if you mean for the first level number only to ever
change when something earth shattering happens, like a framework change or
a complete rewrite of the system,  it will probably never happen,  since
yours is a decently large,  mature project. That is,  if I'm not mistaken,
the realization Linus  came to when he finally bumped the Linux kernel to
3, more or less at random.

I will now go back to lurking in a more appropriately silent way until I
have time to actually be useful.
On Mar 28, 2015 7:02 PM, "Chris Good" <[hidden email]> wrote:

> Hi All,
>
> I've asked for people to give their opinions on a GnuCash version numbering
> system as, from my few small documentation contributions, I think this
> should be defined somewhere.
>
> I'll summarise what I've observed so far now that's it's been a week.
>
> There has been some good input about what the 3 segments of the GnuCash
> version number should be used for, although there is no general consensus
> and some people are OK to leave the decision till later, or maybe decide if
> the first 1 or 2 segments should change on a case by case basis.
>
> We don't seem to be getting anywhere picking names for the 3 segments of
> the
> version number, particularly the first segment.
> We've had the following suggestions (in no particular order):
>
> First Level:
>         Major
>         Architecture
>         Global
>         Fundamental
>         Framework
>         Basic
>         Base (I'm throwing this into the ring here)
> Second Level:
>         Major
>         Minor
> Third Level:
>         Minor
>         Micro
>         Bugfix
>         Point
>         Revision
>         Patch
>
> Have I missed any?
>
> I think it is generally agreed, (from the small number of opinions
> expressed so far), that level 2 should be Major and level 3 should be
> Minor.
> Can everyone that has an opinion please let us know, particularly regarding
> the level 1 name?
>
> Regards,
> Chris Good
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

sunfish62
In reply to this post by ChrisGood
My vote doesn’t count for much, but for me Fundamental.Major.Minor makes the most sense.

David R.’s designation (Major.Minor.Point) also works for me, though—and following convention is something I think is worth an awful lot. There’s something to be said for matching general expectations.

David T.


On Mar 28, 2015, at 4:02 PM, Chris Good <[hidden email]> wrote:

> Hi All,
>
> I've asked for people to give their opinions on a GnuCash version numbering
> system as, from my few small documentation contributions, I think this
> should be defined somewhere.
>
> I'll summarise what I've observed so far now that's it's been a week.
>
> There has been some good input about what the 3 segments of the GnuCash
> version number should be used for, although there is no general consensus
> and some people are OK to leave the decision till later, or maybe decide if
> the first 1 or 2 segments should change on a case by case basis.
>
> We don't seem to be getting anywhere picking names for the 3 segments of the
> version number, particularly the first segment.
> We've had the following suggestions (in no particular order):
>
> First Level:
> Major
> Architecture
> Global
> Fundamental
> Framework
> Basic
> Base (I'm throwing this into the ring here)
> Second Level:
> Major
> Minor
> Third Level:
> Minor
> Micro
> Bugfix
> Point
> Revision
> Patch
>
> Have I missed any?
>
> I think it is generally agreed, (from the small number of opinions
> expressed so far), that level 2 should be Major and level 3 should be Minor.
> Can everyone that has an opinion please let us know, particularly regarding
> the level 1 name?
>
> Regards,
> Chris Good
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Herbert Thoma-2
In reply to this post by ChrisGood
Am 29.03.2015 um 00:02 schrieb Chris Good:
> I think it is generally agreed, (from the small number of opinions
> expressed so far), that level 2 should be Major and level 3 should be Minor.
> Can everyone that has an opinion please let us know, particularly regarding
> the level 1 name?

Well, IIRC, we bumped the first level from 1 to 2 when we switched from
Gnome 1 to Gnome 2. So "historically" it is may be a Framework version.

Gnome 2 support may end some time, so that we will be forced to change
the framework (like last time ...). This could trigger the next first
level version bump. However, this would not feel very good, to be forced
by external dependencies.

On the other hand, Linux recently decided that version number don't have
any meaning at all. They change the first level number when Linus feels
like changing it ...

  Herbert.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Geert Janssens-4
In reply to this post by David Raker
David,

Thank you for your input. It more or less summarizes what I believe is a
pretty common versioning strategy in many free software projects. And
since we are a free software project ourselves we"d need good reasons to
follow a different route as doing so reduces the common knowledge
advantage.

As to the choice of names for the version components I already stated
I'm having major (no pun intended) issues with the "major.minor.x"
scheme. Those may make sense for release managers, but not for users or
developers.

Releases which bump the "minor" component in that scheme have often seen
major new features in the eyes of developers who have spent countless
hours of work on them or users who have been waiting for a long time for
these. If anything, calling such a release a "minor" release is very bad
marketing wise.

That's probably one reason you rarely see such a scheme on commercial
projects. Many projects use years to version their products (Office
2013, Ubuntu 14.04) or rapidly increasing first numbers (Fedora 21,
Windows 7, Firefox 36, Chrome 41,...) and only add rarely add extra
detail (like Windows 8.1 which could be considered as a bugfix release
for Windows 8). OS X is an exception, although Apple is careful to use
zippy names for each release.

Herbert already noted as well that the kernel project no longer really
uses the "major" component. It's just arbitrarily updated.

So there are signs that the traditional meaning of the left-most
component is slowly changing.

As are the times. Many projects are on higher frequency release
schedules, and more and more the distinction between releases for
bugfixes or for new features is being dropped or at least seriously
watered down. For such projects the distinction between
major/minor/bugfix is hard to make.

To be clear gnucash is still very traditional in that respect. Slow
release cycles, stable releases (mostly) bugfix only. That may need some
revision at some point to catch up with the rest of the world. But
that's a totally different discussion.

I'm bringing all of this up to get us the think further than what has
always been, not necessarily because it should change. It all depends on
how much information one wants to code into the version number.

I'm fine with the 3-component versioning scheme. It works for our
purposes and we can indeed decide with each release whether it has
sufficient changes to warant a bump in the left-most component.

On the other hand I also like a year.month-based versioning scheme.
Particularly for users this conveys a lot of information (which may bite
as well if you are on a slow release cycle). I suspect our release model
doesn't fit this versioning scheme though.

I'm also curious how the more rapidly changing first component release
scheme would work for gnucash (which would validate "minor" for the
second component again).

Both of these two releases go for a simplified versioning scheme at the
expense of the amount of information that can be encoded in it. And
personally I don't think gnucash is ready for either if you consider the
compatibility component.

I do prefer the name shift from
major.minor.something
to
fundamental.major.bugfix
though. The first component change happens far too rarely to be called
major. Or more importantly I think minor doesn't do honor to the work
that goes into the big releases we do every 3-4 years.
I'm well aware this goes against the naming conventions usually adhered
to by release managers.

Whew, lots of text again... Congrats if you made it this far.

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

RE: Version Numbering

ChrisGood
Hi John & Geert,

Everybody has had a chance to express their opinion now.
There doesn't seem to be a consensus on what the version number segments
should be called in the community as a whole.
There has been a lot of good information emerge that I would like to
document in to the Development Process wiki section.

If you can both agree on a naming scheme, I think we should go with whatever
you both think.
How about Geert's latest suggestion: fundamental.major.bugfix ?

Or should I just document them as FirstSegment.SecondSegment.ThirdSegment?

Regards,

Chris Good

> -----Original Message-----
> From: Geert Janssens [mailto:[hidden email]]
> Sent: Tuesday, 31 March 2015 1:32 AM
> To: [hidden email]
> Cc: David Raker; Chris Good
> Subject: Re: Version Numbering
>
> David,
>
> Thank you for your input. It more or less summarizes what I believe is a
> pretty common versioning strategy in many free software projects. And
> since we are a free software project ourselves we"d need good reasons to
> follow a different route as doing so reduces the common knowledge
> advantage.
>
> As to the choice of names for the version components I already stated I'm
> having major (no pun intended) issues with the "major.minor.x"
> scheme. Those may make sense for release managers, but not for users or
> developers.
>
> Releases which bump the "minor" component in that scheme have often
> seen major new features in the eyes of developers who have spent
> countless hours of work on them or users who have been waiting for a long
> time for these. If anything, calling such a release a "minor" release is
very bad
> marketing wise.
>
> That's probably one reason you rarely see such a scheme on commercial
> projects. Many projects use years to version their products (Office 2013,
> Ubuntu 14.04) or rapidly increasing first numbers (Fedora 21, Windows 7,
> Firefox 36, Chrome 41,...) and only add rarely add extra detail (like
Windows
> 8.1 which could be considered as a bugfix release for Windows 8). OS X is
an
> exception, although Apple is careful to use zippy names for each release.
>
> Herbert already noted as well that the kernel project no longer really
uses
> the "major" component. It's just arbitrarily updated.
>
> So there are signs that the traditional meaning of the left-most component
is
> slowly changing.
>
> As are the times. Many projects are on higher frequency release schedules,
> and more and more the distinction between releases for bugfixes or for new
> features is being dropped or at least seriously watered down. For such
> projects the distinction between major/minor/bugfix is hard to make.
>
> To be clear gnucash is still very traditional in that respect. Slow
release cycles,
> stable releases (mostly) bugfix only. That may need some revision at some
> point to catch up with the rest of the world. But that's a totally
different
> discussion.
>
> I'm bringing all of this up to get us the think further than what has
always
> been, not necessarily because it should change. It all depends on how much
> information one wants to code into the version number.
>
> I'm fine with the 3-component versioning scheme. It works for our purposes
> and we can indeed decide with each release whether it has sufficient
> changes to warant a bump in the left-most component.
>
> On the other hand I also like a year.month-based versioning scheme.
> Particularly for users this conveys a lot of information (which may bite
as well
> if you are on a slow release cycle). I suspect our release model doesn't
fit this

> versioning scheme though.
>
> I'm also curious how the more rapidly changing first component release
> scheme would work for gnucash (which would validate "minor" for the
> second component again).
>
> Both of these two releases go for a simplified versioning scheme at the
> expense of the amount of information that can be encoded in it. And
> personally I don't think gnucash is ready for either if you consider the
> compatibility component.
>
> I do prefer the name shift from
> major.minor.something
> to
> fundamental.major.bugfix
> though. The first component change happens far too rarely to be called
> major. Or more importantly I think minor doesn't do honor to the work that
> goes into the big releases we do every 3-4 years.
> I'm well aware this goes against the naming conventions usually adhered to
> by release managers.
>
> Whew, lots of text again... Congrats if you made it this far.
>
> Geert

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

John Ralls-2

> On May 30, 2015, at 3:24 PM, Chris Good <[hidden email]> wrote:
>
> Hi John & Geert,
>
> Everybody has had a chance to express their opinion now.
> There doesn't seem to be a consensus on what the version number segments
> should be called in the community as a whole.
> There has been a lot of good information emerge that I would like to
> document in to the Development Process wiki section.
>
> If you can both agree on a naming scheme, I think we should go with whatever
> you both think.
> How about Geert's latest suggestion: fundamental.major.bugfix ?
>
> Or should I just document them as FirstSegment.SecondSegment.ThirdSegment?

Well, I still don’t care much for “fundamental”, but it’s better than anything else we’ve come up with so let’s go with it.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Version Numbering

Geert Janssens-4
On Saturday 30 May 2015 17:12:08 John Ralls wrote:

> > On May 30, 2015, at 3:24 PM, Chris Good <[hidden email]>
> > wrote:
> >
> > Hi John & Geert,
> >
> > Everybody has had a chance to express their opinion now.
> > There doesn't seem to be a consensus on what the version number
> > segments should be called in the community as a whole.
> > There has been a lot of good information emerge that I would like to
> > document in to the Development Process wiki section.
> >
> > If you can both agree on a naming scheme, I think we should go with
> > whatever you both think.
> > How about Geert's latest suggestion: fundamental.major.bugfix ?
> >
> > Or should I just document them as
> > FirstSegment.SecondSegment.ThirdSegment?
> Well, I still don’t care much for “fundamental”, but it’s better than
> anything else we’ve come up with so let’s go with it.
>
> Regards,
> John Ralls

Agreed.

Geert

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel