-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Dear all, in R14.1.x and in the somehow upcoming R14.0.1 release, tdevelop has reverted to use .kdevelop project files instead of .tdevelop files. Also, the main entry in such file was reverted to "kdevelop" instead of "tdevelop". This has been done to improve compatibility with KDevelop3 project files. When you switch to the "new" version, you will need the following renaming: 1) .tdevelop files -> .kdevelop 2) .tdevelop.filelist files -> .kdevelop.filelist 3) change <tdevelop> to <kdevelop> in any .kdevelop file 4) change </tdevelop> to </kdevelop> in any .kdevelop file
Cheers Michele
I personally disagree with this move, because your initial idea was to make R14 tde compatible and the rest was left for the KDE 3.15. Why moving back now?! What is the benefit of this?I really dislike changing things back and forth and on top after TDE stated that R14 will be TDE oriented.Could such things be discussed in the public please.
regards
On Wednesday, June 17, 2015 8:50 AM, Michele Calgaro michele.calgaro@yahoo.it wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Dear all, in R14.1.x and in the somehow upcoming R14.0.1 release, tdevelop has reverted to use .kdevelop project files instead of .tdevelop files. Also, the main entry in such file was reverted to "kdevelop" instead of "tdevelop". This has been done to improve compatibility with KDevelop3 project files. When you switch to the "new" version, you will need the following renaming: 1) .tdevelop files -> .kdevelop 2) .tdevelop.filelist files -> .kdevelop.filelist 3) change <tdevelop> to <kdevelop> in any .kdevelop file 4) change </tdevelop> to </kdevelop> in any .kdevelop file
Cheers Michele
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
I personally disagree with this move, because your initial idea was to make R14 tde compatible and the rest was left for the KDE 3.15. Why moving back now?! What is the benefit of this?I really dislike changing things back and forth and on top after TDE stated that R14 will be TDE oriented.Could such things be discussed in the public please.
regards
Some of this might be due to the fact that I've been largely unavailable for the past several months (life / putting food on the table), therefore I think my original goals of migrating everything from KDE to TDE have stalled.
Michele, what is the actual benefit of maintaining compatibility with the obsolete KDE 3.5 series instead of automatically upgrading the kdevelop files to a TDE format? There is no guarantee that KDE will continue to use a compatible format in the future so I don't see how this is a good idea?
Thanks!
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 06/18/2015 02:03 AM, Timothy Pearson wrote:
I personally disagree with this move, because your initial idea was to make R14 tde compatible and the rest was left for the KDE 3.15. Why moving back now?! What is the benefit of this?I really dislike changing things back and forth and on top after TDE stated that R14 will be TDE oriented.Could such things be discussed in the public please.
regards
Some of this might be due to the fact that I've been largely unavailable for the past several months (life / putting food on the table), therefore I think my original goals of migrating everything from KDE to TDE have stalled.
Michele, what is the actual benefit of maintaining compatibility with the obsolete KDE 3.5 series instead of automatically upgrading the kdevelop files to a TDE format? There is no guarantee that KDE will continue to use a compatible format in the future so I don't see how this is a good idea?
Thanks!
Tim
Hi there, the details of the discussion prior the changes were made can be found here (http://bugs.pearsoncomputing.net/show_bug.cgi?id=2308#c2). The change was made to assure we could still autogenerate cmake-based projects. Without doing so, it would render any "cmake based" project template unusable due to the fact that there is no TDevelop3 cmake generator available (and I doubt the cmake guys would create one just for us).
Basically TDE is still going the TDE way, but had to concede on this point to preserve some useful functionality. Everything can be reverted if the majority of the users prefer so, but be aware that in this case this would come at a small loss of that extra functioanlity.
Cheers Michele
On Thursday 18 of June 2015 01:09:32 Michele Calgaro wrote:
On 06/18/2015 02:03 AM, Timothy Pearson wrote:
I personally disagree with this move, because your initial idea was to make R14 tde compatible and the rest was left for the KDE 3.15. Why moving back now?! What is the benefit of this?I really dislike changing things back and forth and on top after TDE stated that R14 will be TDE oriented.Could such things be discussed in the public please.
regards
Some of this might be due to the fact that I've been largely unavailable for the past several months (life / putting food on the table), therefore I think my original goals of migrating everything from KDE to TDE have stalled.
Michele, what is the actual benefit of maintaining compatibility with the obsolete KDE 3.5 series instead of automatically upgrading the kdevelop files to a TDE format? There is no guarantee that KDE will continue to use a compatible format in the future so I don't see how this is a good idea?
Thanks!
Tim
Hi there, the details of the discussion prior the changes were made can be found here (http://bugs.pearsoncomputing.net/show_bug.cgi?id=2308#c2). The change was made to assure we could still autogenerate cmake-based projects. Without doing so, it would render any "cmake based" project template unusable due to the fact that there is no TDevelop3 cmake generator available (and I doubt the cmake guys would create one just for us).
Basically TDE is still going the TDE way, but had to concede on this point to preserve some useful functionality. Everything can be reverted if the majority of the users prefer so, but be aware that in this case this would come at a small loss of that extra functioanlity.
Cheers Michele
Preserving data compatibility seems to me useful.
For example, some time ago due to the renaming KWallet => TDEWallet was caused incompatibility of data files with stored passwords. Therefore are reverted portion of renaming data file header so that the data files could still be compatible with KWallet. It seems like a good reason to have a compatible files until will be necessary to change the stored data, which compels to change format of data files.
-
Emanoil Kotsev -
Michele Calgaro -
Slávek Banko -
Timothy Pearson