hello all, I just want to add some thoughts on the version discussion that just happened on IRC. (I admit I'm just too slow in thinking an writing simultaneously in a foreign language, so I could not express much in there :) so here goes: the outcome of the discussion, naming the next version R14 or R14.0, seems not very attractive nor logic to me, it makes people IMHO think there have been 14 _major_ releases before. looks like the same versionitis that firefox, chrome or others use nowadays, in short: pretending huge changes happening every 6 months or so. not good. of course, there was also agreement that nothing with 4.x should be used, for obvious reasons ;-) same goes for 5.x, though. date based release numbers resemble too much to *buntu, not a good idea, too, agreed. so why not start over with 3.6 ? this would IMO be a clear sign for all users who still like kde 3.5.x, that this project stands in a direct relationship to kde 3.5, but at the same time, is _not_ just an incremental continuation like 3.5.13, but rather a new start, well based on 3.5, but bringing new technology and features as well, basically different from the kde4 approach, however. just my 0.02 €
werner
I just want to add some thoughts on the version discussion that just happened on IRC. (I admit I'm just too slow in thinking an writing simultaneously in a foreign language, so I could not express much in there :) so here goes: the outcome of the discussion, naming the next version R14 or R14.0, seems not very attractive nor logic to me, it makes people IMHO think there have been 14 _major_ releases before. looks like the same versionitis that firefox, chrome or others use nowadays, in short: pretending huge changes happening every 6 months or so. not good. of course, there was also agreement that nothing with 4.x should be used, for obvious reasons ;-) same goes for 5.x, though. date based release numbers resemble too much to *buntu, not a good idea, too, agreed. so why not start over with 3.6 ? this would IMO be a clear sign for all users who still like kde 3.5.x, that this project stands in a direct relationship to kde 3.5, but at the same time, is _not_ just an incremental continuation like 3.5.13, but rather a new start, well based on 3.5, but bringing new technology and features as well, basically different from the kde4 approach, however. just my 0.02 €
I'm okay with R14, 3.5.14, or 3.6. :) If we change the version with the next release, then we should post an announcment at the web site now, after agreeing to the new version number. Give people a heads up now.
I don't have a problem with the next release being 3.5.14, but I think a few folks want to move out of the KDE shadow as soon as possible. I agree with the sentiment.
R14 makes sense as that number provides a link/bridge to 3.15.14 and the past version numbers.
The web site home page should say (now) that the next version will start a new versioning scheme. That is all that needs to be said. The more we try to explain why we are changing the more confusion we raise and the more doors that open from Trinity opposition. Any announcment should focus on NOT discussing the reason for the change as getting out of the KDE shadow.
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment (TDE) will change with the next release, tentatively scheduled for May 2012. The current version is 3.5.13 and the next version will be R14. Under the current version scheme the next version would be 3.5.14. Using R14 is a simple way of connecting to past version numbers yet start a new version scheme.
Bug fix and security releases will be noted in the new version scheme by ... (somebody else complete this statement.) ===========================
Darrell
I'm okay with R14, 3.5.14, or 3.6. :) If we change the version with the next release, then we should post an announcment at the web site now, after agreeing to the new version number. Give people a heads up now.
I don't have a problem with the next release being 3.5.14, but I think a few folks want to move out of the KDE shadow as soon as possible. I agree with the sentiment.
R14 makes sense as that number provides a link/bridge to 3.15.14 and the past version numbers.
The web site home page should say (now) that the next version will start a new versioning scheme. That is all that needs to be said. The more we try to explain why we are changing the more confusion we raise and the more doors that open from Trinity opposition. Any announcment should focus on NOT discussing the reason for the change as getting out of the KDE shadow.
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment (TDE) will change with the next release, tentatively scheduled for May 2012. The current version is 3.5.13 and the next version will be R14. Under the current version scheme the next version would be 3.5.14. Using R14 is a simple way of connecting to past version numbers yet start a new version scheme.
Bug fix and security releases will be noted in the new version scheme by ... (somebody else complete this statement.) ===========================
Darrell
Both you and Julius stated the reasoning quite well!
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Tim
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment
(TDE) will change
with the next release, tentatively scheduled for May
- The current
version is 3.5.13 and the next version will be R14.
Under the current
version scheme the next version would be 3.5.14. Using
R14 is a simple way
of connecting to past version numbers yet start a new
version scheme.
Bug fix and security releases will be noted in the new
version scheme by
... (somebody else complete this statement.)
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Sounds good. No rush, plenty of time yet. Save the proposed announcment and edit to taste. :)
Probably a good idea to have at least one other person besides you make a run at building packages from GIT using the new version number. Basic quality assurance. :)
I don't think we agreed on versions for bug fixes and security patches.
Proposal:
I don't want to see the version number increment by one whole number every release --- like the joke that Mozilla uses for Firefox. People are likely to presume we are doing that simply to create big version numbers, which fools nobody and impresses nobody.
For example, the next version in May 2012 will be R14.0. If there is a security patch or serious bug fix before the next official release, then use the alphabet to bump the version: R14.0a. If the next official release introduces nothing major with respect to development, then the next release thereafter would be R14.1.
Darrell
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Sounds good. No rush, plenty of time yet. Save the proposed announcment and edit to taste. :)
Probably a good idea to have at least one other person besides you make a run at building packages from GIT using the new version number. Basic quality assurance. :)
I don't think we agreed on versions for bug fixes and security patches.
Proposal:
I don't want to see the version number increment by one whole number every release --- like the joke that Mozilla uses for Firefox. People are likely to presume we are doing that simply to create big version numbers, which fools nobody and impresses nobody.
For example, the next version in May 2012 will be R14.0. If there is a security patch or serious bug fix before the next official release, then use the alphabet to bump the version: R14.0a. If the next official release introduces nothing major with respect to development, then the next release thereafter would be R14.1.
Darrell
This is the approach I was considering. I also though this was at least discussed during the meeting, but it is possible that no decision was reached.
Basically the numbering would be: R <ABI version> . <bugfix version> . <security patch version>
By definition no major improvements would imply any changes are bugfixes, so it should work as intended. :-)
Tim
On 15 November 2011 14:54, Darrell Anderson humanreadable@yahoo.com wrote:
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment
(TDE) will change
with the next release, tentatively scheduled for May
- The current
version is 3.5.13 and the next version will be R14.
Under the current
version scheme the next version would be 3.5.14. Using
R14 is a simple way
of connecting to past version numbers yet start a new
version scheme.
Bug fix and security releases will be noted in the new
version scheme by
... (somebody else complete this statement.)
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Sounds good. No rush, plenty of time yet. Save the proposed announcment and edit to taste. :)
Probably a good idea to have at least one other person besides you make a run at building packages from GIT using the new version number. Basic quality assurance. :)
I don't think we agreed on versions for bug fixes and security patches.
Proposal:
I don't want to see the version number increment by one whole number every release --- like the joke that Mozilla uses for Firefox. People are likely to presume we are doing that simply to create big version numbers, which fools nobody and impresses nobody.
For example, the next version in May 2012 will be R14.0. If there is a security patch or serious bug fix before the next official release, then use the alphabet to bump the version: R14.0a. If the next official release introduces nothing major with respect to development, then the next release thereafter would be R14.1.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Aye,
But technically there have been 13 releases of the 3.5 series.
Aye,
But technically there have been 13 releases of the 3.5 series.
True, but I believe the consensus feeling is to break from the KDE shadow. Explaining in the announcment that 3.5.14 would have been the 14th release of the 3.5 series is factual but keeps the shadow alive.
In my proposed About/FAQ in etherpad, I have a short History section that recognizes Trinity's roots from 3.5.10. We don't deny that heritage, but the new versioning system is intended to develop a unique Trinity personality. So too with the announcement. :)
Darrell
On Tue, Nov 15, 2011 at 7:59 PM, Calvin Morrison mutantturkey@gmail.comwrote:
On 15 November 2011 14:54, Darrell Anderson humanreadable@yahoo.comwrote:
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment
(TDE) will change
with the next release, tentatively scheduled for May
- The current
version is 3.5.13 and the next version will be R14.
Under the current
version scheme the next version would be 3.5.14. Using
R14 is a simple way
of connecting to past version numbers yet start a new
version scheme.
Bug fix and security releases will be noted in the new
version scheme by
... (somebody else complete this statement.)
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Sounds good. No rush, plenty of time yet. Save the proposed announcment and edit to taste. :)
Probably a good idea to have at least one other person besides you make a run at building packages from GIT using the new version number. Basic quality assurance. :)
I don't think we agreed on versions for bug fixes and security patches.
Proposal:
I don't want to see the version number increment by one whole number every release --- like the joke that Mozilla uses for Firefox. People are likely to presume we are doing that simply to create big version numbers, which fools nobody and impresses nobody.
For example, the next version in May 2012 will be R14.0. If there is a security patch or serious bug fix before the next official release, then use the alphabet to bump the version: R14.0a. If the next official release introduces nothing major with respect to development, then the next release thereafter would be R14.1.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Aye,
But technically there have been 13 releases of the 3.5 series.
Nope, there have been 10 bugfix releases and 3 releases that IMHO were wrongly still in the 3.5 series, since they included what I myself consider big changes and new features.
Best regards, Tiago
On 11/15/2011 02:54 PM, Darrell Anderson wrote:
=========================== Proposed announcement:
The version number for the Trinity Desktop Environment
(TDE) will change
with the next release, tentatively scheduled for May
- The current
version is 3.5.13 and the next version will be R14.
Under the current
version scheme the next version would be 3.5.14. Using
R14 is a simple way
of connecting to past version numbers yet start a new
version scheme.
Bug fix and security releases will be noted in the new
version scheme by
... (somebody else complete this statement.)
Regarding the announcement, let's hold off until Dec. 1st. That will allow me to finish the GIT migration and actually get the new version number into the code repository.
Sounds good. No rush, plenty of time yet. Save the proposed announcment and edit to taste. :)
Probably a good idea to have at least one other person besides you make a run at building packages from GIT using the new version number. Basic quality assurance. :)
I don't think we agreed on versions for bug fixes and security patches.
Proposal:
I don't want to see the version number increment by one whole number every release --- like the joke that Mozilla uses for Firefox. People are likely to presume we are doing that simply to create big version numbers, which fools nobody and impresses nobody.
For example, the next version in May 2012 will be R14.0. If there is a security patch or serious bug fix before the next official release, then use the alphabet to bump the version: R14.0a. If the next official release introduces nothing major with respect to development, then the next release thereafter would be R14.1.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I like TDE YYYYMMDD then you know its vintage.
If you have a bug fix then the version number is simple
hello all, I just want to add some thoughts on the version discussion that just happened on IRC. (I admit I'm just too slow in thinking an writing simultaneously in a foreign language, so I could not express much in there :) so here goes: the outcome of the discussion, naming the next version R14 or R14.0, seems not very attractive nor logic to me, it makes people IMHO think there have been 14 _major_ releases before. looks like the same versionitis that firefox, chrome or others use nowadays, in short: pretending huge changes happening every 6 months or so. not good. of course, there was also agreement that nothing with 4.x should be used, for obvious reasons ;-) same goes for 5.x, though. date based release numbers resemble too much to *buntu, not a good idea, too, agreed. so why not start over with 3.6 ? this would IMO be a clear sign for all users who still like kde 3.5.x, that this project stands in a direct relationship to kde 3.5, but at the same time, is _not_ just an incremental continuation like 3.5.13, but rather a new start, well based on 3.5, but bringing new technology and features as well, basically different from the kde4 approach, however. just my 0.02 â¬
werner
Hi Werner,
The biggest problems with that approach are: 1.) KDE4.x / 5.x will always seem "newer" than TDE, and therefore overshadown it 2.) Closely related with 1.), TDE will always exist in KDE's shadow and never stand on its own merits.
Tim
On Tuesday 15 November 2011 20:31:01 Timothy Pearson wrote:
The biggest problems with that approach are: 1.) KDE4.x / 5.x will always seem "newer" than TDE, and therefore overshadown it 2.) Closely related with 1.), TDE will always exist in KDE's shadow and never stand on its own merits.
these are arguments to be considered, I agree. still not very comfortable with the 14.x approach, though :)
werner
Hi Werner,
Werner Joss wrote:
so why not start over with 3.6 ?
Because this implies Trinity would still try to follow KDE's version scheme based on binary compatibility.
Since there are no plans for binary compatibility between releases, anything that would appear to be based on KDE's versioning could be confusing.
Right now I think the "three" part is nicely covered within the name already, so I don't think there is a need to resemble that anywhere else.
Best regards, Julius
On Tuesday 15 November 2011 20:31:55 Julius Schwartzenberg wrote:
Right now I think the "three" part is nicely covered within the name already, so I don't think there is a need to resemble that anywhere else.
godd point, indeed :)
werner
-
Calvin Morrison -
Darrell Anderson -
Julius Schwartzenberg -
scrat -
Tiago Marques -
Timothy Pearson -
Werner Joss