I like a good argument more than a good program, so let's see if we can't puzzle his out some more:
Subject: Major.Minor.Patch vs. Date.Time.Type
Major....etc
Pros:
1. Consistent with most software.
2. You know what has been changed with each new version number
Cons:
1. Version Numbers can be arbitrary
2. Version Numbers restrict what is released when
Date.....etc
Pros:
1. Version numbers directly related to date.
2. .release, etc. lets use know what has been changed with each release
3. Unrestricted development, add what you want, when you want, so long as it works.
Cons:
1. Inconsitent with most software.
2. User may be forced to read release notes to get an idea of just how major a release is.
At this point, since with Major...etc you end up having to read release notes anyway to find out what sepcifically has changed, I am siding with Date....etc.
What pros and cons do you see?
PS.
Proposed Date Format:
Date.Time.Type
2004.04.19.16:00.beta
Date released . Time of release . Type of release
Where types are:
alpha - Some stuff might work
beta - Most stuff should work
release - All stuff should work, Changes/New Features Added,
Bugs Fixed.
patch - Bugs Fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The other way how version numbers can be harmful is that they can even hold off new releases! Authors often have some idea about what splendid new features a new major release should have, and won't release it until all of them are implemented. Moreover, often more and more features come in, and the release is hold back for ages." - http://netrik.sourceforge.net/?versions.html
"So there will probably be more releases as there have been last year. However it is illusory to state in advance how stable a release is going to be... unless we go through very long test cycles, which we obviously cannot afford.
Thus, the downloads page will now give extended information about each release, especially how stable it has proven to be.
I have been reading up, and I do not agree with all of the conclusions, but I do think the current numbering system limits developers, and what goes in where. Perhaps something wholly new is necessary.
Now I am thinking:
Date.Type.Iteration:
2004.04.19.release.0
We should develop the "Type" tag more, but I believe thi is the best solution.
I would now say the tags should be:
cvs-snapshot
release
patch
What thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Who said version numbers had to be contigious? All they have to do is express the relationship between versions (which is older and which is newer). The biggest problem with this date-based scheme is the lack of information about the stability of the release (stable, release candidate, developer-only...) or it's "importance" (major new revision, minor revision, maintance release, etc)." So now am thinking:
2004.19.04.major.0
Where Date and Iteration remain, but Type
is now:
Major, Minor, Maintenance/Patch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with indicating how stable a release is based upon feedback, is that you end up having to rename the same download after it's been released. It may be released as "2004.04.19.unknown.0", and having proven to be stable it would need to be renamed "2004.04.19.stable.0". The suggestion is that changes have been made when the only change is that feedback has been good.
I don't in all honesty think there is a problem just using the major.minor.patch version numbering scheme, you just need to be make a decision on when to increment which number. It puts releases in an obvious cronological order, with patch increments indicating minor changes and bug fixes, minor version numbers indicating the addition of one or more new features, and a major version number indicating that the software has progressed significantly since the last major release (e.g. 2.0.0) and you want to signify this to your audience of end-users, and maybe sit back and start the software off for a while.
I'd suggest the next major version number increment would happen once the software is MDI only, has multiple resizeable panes, a project manager and codemarks/to-do list. Each one of these would warrant an increment to the minor version number as they were added.
Just my thoughts, and at the end of the day, i don't think it will make any real difference to anything. It's just more of a mental distraction when each new zipped up release comes around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is important, as it is a means of presenting DrPython to the world. It is of rhetorical significance whether or not we use the default scheme.
*
There would be no unknown. I just included that statement since it notes that you can't really determine the stability of something pre-release.
I am concerned because:
1. I cannot add stuff I have marked for 2.5.x, because I still have work on 2.4.x to complete first.
2. I have to decide whether or not to make the next big version 2.5.x or 3.0.x.
3. I could end up at version 6 or 7 in a year. That seems a bit much.
Then again, DrScheme is at version 206p1.
They just have the one number. Perhaps:
Version.Revision would be the best way to go.
Thus the next drpy would be 3.0, followed by 4.0, etc, with small changes yielding an increment of 0.1.
However I think
2004.04.19.major.0
is the best,
Date, Type of Release, Release Number That Day.
maybe just major/minor/patch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is only a problem if you decide that specific features are going to appear in a certain version i.e. "abc" in v2.5, "xyz" in v3.0. If you were simply to make public the order in which you as a developer are going to implement new features, and use the minor/patch numbers to signify when some new and significant functionality has been added (minor) or bugs have been fixed or minor functionality changes made (patch) people will have a much better idea of what has changed just from the version number.
I've seen a lot of research myself, and concluded that the only two considerations are that the numbers be incremental in some way, so as to put releases in cronological order, and that you have a pre-determined, agreed (possibly even published) and therefore predictable numbering scheme. All projects have their own approach, and users very quickly get to know and accept this approach. If we have simple rules - as detailed above or similar, then version numbering becomes almost automatic and stress free.
The certain features in certain future version numbers idea also falls down when there are several developers working on a piece of software independently, which is the case now with DrPython. When I have the project manager finished, its addition should be marked by a minor version increment. Likewise removal of the SDI and incorporation of sizeable panes should also be signified by minor version increments.
When it comes to major version numbers, the way to go is simply to draw a line once you have a good list of planned new features and say, "Right, that's it. Version 3.0 will include all of these features, which will be added in the order they are ready." You then have a specific goal, but can complete the features in any order that's practical, and developers can pretty much add their new features independently rather than waiting for Fred to finish his bit before Barny can add his just to keep the pre-planned version numbers.
I always find it disappointing when a new major version of a piece of software comes out and is only a few minor new features and bug fixes. Major versions should be exactly that - major versions which are significantly improved over the last major version. A major version should be an opportunity to look at branding (in a commercial environment), promotion, updating documentation (prior to the major release) and taking a couple of days break to rest the brain and congratulate yourself on a job well done.
I feel that dates in version numbers are unnecessary, especially when files are released on the internet (and especailly via sourceforge) as alongside the download is the date it was released. A good version numbering scheme gives you an immediate indication of what has been added, whereas a date-based filename does not. For example, three releases dated 01/-, 02/- and 03/- of the month may include a few bug fixes and a slight change in one case and a nice new shiny feature in the other, but you'd have no way of knowing just from the filename unless the major version number was incremented for each new feature, and that, especially when compared to other modern open-source version numbering schemes is just plain wrong. The major version number would no longer indicate what is suggests.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, this is a community project, so I am going to go with the voice of the community, and stick with what we have.
In terms of immediate development, I intend on fixing some more bugs (and removing or fixing the european keyboard bit), and releasing 2.4.6.
Then I will change the cvs version to 3.0.0, and we can add stuff.
Once all of the features listed in the to do list are implemented, the very next release will be 3.0.
If we decided to make 2.5.x, 2.6.x releases on the way, that is cool. However I think once DrPython is MDI only, the panes are redone (and dynamic), plus autocomplete, and all the other stuff is in, DrPython will have changed enough to warrent a big number shift. Plus, I intend on switching two more big things, which I will post seperately on.
Cheers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version numbers seem, well, stupid.
I was thinking about switching to:
year.month.day.iteration
so
2.4.5 would be
2004.04.19.0
What do people think?
Any Other Suggestions?
Other possiblities include leaving it the same:
major.minor.patch, but anyone familiar with DrPython
knows I have not been following this, so much as
huge.major-minor.minor-patch.
Ugh.
I could also:
year.month.day.hour.minute
2004.04.19.22.06
Or
number
126, where number is simply th number of the release
(I could get past version 100 in no time at all!)
Personally I like the idea of switching to some varation of the date format, but I would like to get some feedback.
I prefer 2.4.5. Most software like this.
The reason this would be better, is I could just add stuff, and the road map would be less of a burden on what I add, and when.
In terms of practicality, the reasoning behind ,ajor.minor.patch, is the user knows what they are getting. I rearely follow this.
However a variation, like
2004.04.19.0.release
would let you know what you get.
the string part of it could be:
.release (new features added)
.patch (bugs fixed)
of course a release could have bugs fixed too.
this way users can differentiate, and the numbers are no longer arbitrary.
But you can put the 2004.04.19.0.release in About dialog, if someone wants to know.
I like a good argument more than a good program, so let's see if we can't puzzle his out some more:
Subject: Major.Minor.Patch vs. Date.Time.Type
Major....etc
Pros:
1. Consistent with most software.
2. You know what has been changed with each new version number
Cons:
1. Version Numbers can be arbitrary
2. Version Numbers restrict what is released when
Date.....etc
Pros:
1. Version numbers directly related to date.
2. .release, etc. lets use know what has been changed with each release
3. Unrestricted development, add what you want, when you want, so long as it works.
Cons:
1. Inconsitent with most software.
2. User may be forced to read release notes to get an idea of just how major a release is.
At this point, since with Major...etc you end up having to read release notes anyway to find out what sepcifically has changed, I am siding with Date....etc.
What pros and cons do you see?
PS.
Proposed Date Format:
Date.Time.Type
2004.04.19.16:00.beta
Date released . Time of release . Type of release
Where types are:
alpha - Some stuff might work
beta - Most stuff should work
release - All stuff should work, Changes/New Features Added,
Bugs Fixed.
patch - Bugs Fixed.
"The other way how version numbers can be harmful is that they can even hold off new releases! Authors often have some idea about what splendid new features a new major release should have, and won't release it until all of them are implemented. Moreover, often more and more features come in, and the release is hold back for ages." - http://netrik.sourceforge.net/?versions.html
"So there will probably be more releases as there have been last year. However it is illusory to state in advance how stable a release is going to be... unless we go through very long test cycles, which we obviously cannot afford.
Thus, the downloads page will now give extended information about each release, especially how stable it has proven to be.
You can help us with this goal, just by telling us how comfortable you feel with each new release once you have used it for a while." - http://b2evolution.net/news.php/2004/04/12/p2204-Version_numbering
I have been reading up, and I do not agree with all of the conclusions, but I do think the current numbering system limits developers, and what goes in where. Perhaps something wholly new is necessary.
Now I am thinking:
Date.Type.Iteration:
2004.04.19.release.0
We should develop the "Type" tag more, but I believe thi is the best solution.
I would now say the tags should be:
cvs-snapshot
release
patch
What thoughts?
"Who said version numbers had to be contigious? All they have to do is express the relationship between versions (which is older and which is newer). The biggest problem with this date-based scheme is the lack of information about the stability of the release (stable, release candidate, developer-only...) or it's "importance" (major new revision, minor revision, maintance release, etc)." So now am thinking:
2004.19.04.major.0
Where Date and Iteration remain, but Type
is now:
Major, Minor, Maintenance/Patch
The problem with indicating how stable a release is based upon feedback, is that you end up having to rename the same download after it's been released. It may be released as "2004.04.19.unknown.0", and having proven to be stable it would need to be renamed "2004.04.19.stable.0". The suggestion is that changes have been made when the only change is that feedback has been good.
I don't in all honesty think there is a problem just using the major.minor.patch version numbering scheme, you just need to be make a decision on when to increment which number. It puts releases in an obvious cronological order, with patch increments indicating minor changes and bug fixes, minor version numbers indicating the addition of one or more new features, and a major version number indicating that the software has progressed significantly since the last major release (e.g. 2.0.0) and you want to signify this to your audience of end-users, and maybe sit back and start the software off for a while.
I'd suggest the next major version number increment would happen once the software is MDI only, has multiple resizeable panes, a project manager and codemarks/to-do list. Each one of these would warrant an increment to the minor version number as they were added.
Just my thoughts, and at the end of the day, i don't think it will make any real difference to anything. It's just more of a mental distraction when each new zipped up release comes around.
This is important, as it is a means of presenting DrPython to the world. It is of rhetorical significance whether or not we use the default scheme.
*
There would be no unknown. I just included that statement since it notes that you can't really determine the stability of something pre-release.
I am concerned because:
1. I cannot add stuff I have marked for 2.5.x, because I still have work on 2.4.x to complete first.
2. I have to decide whether or not to make the next big version 2.5.x or 3.0.x.
3. I could end up at version 6 or 7 in a year. That seems a bit much.
Then again, DrScheme is at version 206p1.
They just have the one number. Perhaps:
Version.Revision would be the best way to go.
Thus the next drpy would be 3.0, followed by 4.0, etc, with small changes yielding an increment of 0.1.
However I think
2004.04.19.major.0
is the best,
Date, Type of Release, Release Number That Day.
maybe just major/minor/patch.
You can use major.minor.patch.yyyy.mm.dd, but it's too long. :)
Or release.yyyy.mm.dd shortly.
This is only a problem if you decide that specific features are going to appear in a certain version i.e. "abc" in v2.5, "xyz" in v3.0. If you were simply to make public the order in which you as a developer are going to implement new features, and use the minor/patch numbers to signify when some new and significant functionality has been added (minor) or bugs have been fixed or minor functionality changes made (patch) people will have a much better idea of what has changed just from the version number.
I've seen a lot of research myself, and concluded that the only two considerations are that the numbers be incremental in some way, so as to put releases in cronological order, and that you have a pre-determined, agreed (possibly even published) and therefore predictable numbering scheme. All projects have their own approach, and users very quickly get to know and accept this approach. If we have simple rules - as detailed above or similar, then version numbering becomes almost automatic and stress free.
The certain features in certain future version numbers idea also falls down when there are several developers working on a piece of software independently, which is the case now with DrPython. When I have the project manager finished, its addition should be marked by a minor version increment. Likewise removal of the SDI and incorporation of sizeable panes should also be signified by minor version increments.
When it comes to major version numbers, the way to go is simply to draw a line once you have a good list of planned new features and say, "Right, that's it. Version 3.0 will include all of these features, which will be added in the order they are ready." You then have a specific goal, but can complete the features in any order that's practical, and developers can pretty much add their new features independently rather than waiting for Fred to finish his bit before Barny can add his just to keep the pre-planned version numbers.
I always find it disappointing when a new major version of a piece of software comes out and is only a few minor new features and bug fixes. Major versions should be exactly that - major versions which are significantly improved over the last major version. A major version should be an opportunity to look at branding (in a commercial environment), promotion, updating documentation (prior to the major release) and taking a couple of days break to rest the brain and congratulate yourself on a job well done.
I feel that dates in version numbers are unnecessary, especially when files are released on the internet (and especailly via sourceforge) as alongside the download is the date it was released. A good version numbering scheme gives you an immediate indication of what has been added, whereas a date-based filename does not. For example, three releases dated 01/-, 02/- and 03/- of the month may include a few bug fixes and a slight change in one case and a nice new shiny feature in the other, but you'd have no way of knowing just from the filename unless the major version number was incremented for each new feature, and that, especially when compared to other modern open-source version numbering schemes is just plain wrong. The major version number would no longer indicate what is suggests.
Well, this is a community project, so I am going to go with the voice of the community, and stick with what we have.
In terms of immediate development, I intend on fixing some more bugs (and removing or fixing the european keyboard bit), and releasing 2.4.6.
Then I will change the cvs version to 3.0.0, and we can add stuff.
Once all of the features listed in the to do list are implemented, the very next release will be 3.0.
If we decided to make 2.5.x, 2.6.x releases on the way, that is cool. However I think once DrPython is MDI only, the panes are redone (and dynamic), plus autocomplete, and all the other stuff is in, DrPython will have changed enough to warrent a big number shift. Plus, I intend on switching two more big things, which I will post seperately on.
Cheers.