Hi, As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that. People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2. int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added : dancer_major_version, which returns what's on the left of the dot in the version number. Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword) What's the best solution ? In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all 2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins. 3/ any idea ? As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change. In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is dams.
Basically, Dancer and plugins are doing version numbers and version number comparison wrong. Yes, I am an authority on this. ;-) My suggestion, given the current state of affairs, is that dancer_version in the 1.999_XX dev series should be hardcoded to 2 in advance of the actual 2.0 release. If you want to be fancy, something like this: sub dancer_version { Dancer->VERSION lt 2 ? 2 : Dancer->VERSION } That decouples the version that plugins see from the module versioning. David On Tue, Dec 25, 2012 at 5:59 PM, damien krotkine <dkrotkine@gmail.com> wrote:
Hi,
As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that.
People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2.
int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added :
dancer_major_version, which returns what's on the left of the dot in the version number.
Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword)
What's the best solution ?
In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all
2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins.
3/ any idea ?
As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change.
In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is
dams.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Le mercredi 26 décembre 2012 à 17:45, David Golden a écrit :
Basically, Dancer and plugins are doing version numbers and version number comparison wrong. Yes, I am an authority on this. ;-)
We believe you ! :)
My suggestion, given the current state of affairs, is that dancer_version in the 1.999_XX dev series should be hardcoded to 2 in advance of the actual 2.0 release. If you want to be fancy, something like this:
sub dancer_version { Dancer->VERSION lt 2 ? 2 : Dancer->VERSION }
That decouples the version that plugins see from the module versioning.
That's a good idea. Looking at the current code in Dancer.pm I don't understand the code of the VERSION method anyway :) I think sukria agrees to remove the API version thingy. There is also an API version in App.pm that should be removed. And dancer_api_version should go away imho, as I doesn't exist in dancer 1 DSL.
David
On Tue, Dec 25, 2012 at 5:59 PM, damien krotkine <dkrotkine@gmail.com> wrote:
Hi,
As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that.
People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2.
int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added :
dancer_major_version, which returns what's on the left of the dot in the version number.
Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword)
What's the best solution ?
In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all
2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins.
3/ any idea ?
As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change.
In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is
dams.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Wed, 26 Dec 2012, Damien Krotkine wrote:
Le mercredi 26 décembre 2012 à 17:45, David Golden a écrit :
Basically, Dancer and plugins are doing version numbers and version number comparison wrong. Yes, I am an authority on this. ;-)
We believe you ! :)
I do not believe David Golden wrote "We believe you". Is Damien Krotkine an authority on version numbers? Please insert some indent chars. -- The answer before the question. What is unreadable?
On Wed, Dec 26, 2012 at 9:33 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
I do not believe David Golden wrote "We believe you". Is Damien Krotkine an authority on version numbers?
Please insert some indent chars.
FWIW, it rendered correctly on my gmail. -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
On Wed, 26 Dec 2012, David Golden wrote:
On Wed, Dec 26, 2012 at 9:33 PM, Henk van Oers <hvo.pm@xs4all.nl> wrote:
[/me having problems reading]
Please insert some indent chars.
FWIW, it rendered correctly on my gmail.
You are right. Looking at the raw message I see the indent chars. It's a bug in my MUA. Sorry for the noise, -- Henk
Actually, the whole thing is that dancer_version (or major_version) should clearly not be used for plugins to check their compatibility with the core. Actually, what plugin should do is to use api_version. Simple example : Dancer 1.9999_01 is "Dancer 1" is you look at the VERSION (whatever method you choose) but it's actually "Dancer 2" regarding its core. So to summarize: - dancer_major_version should be removed, it has been added in a rush, while releasing 1.9999_01 but was a mistake because of the reason explained above - api_version should be used whenever something needs to check its compatibility with the core 2012/12/25 damien krotkine <dkrotkine@gmail.com>
Hi,
As I understand, Alexis did a dev release of dancer2. The version is 1.9999_01 or something like that.
People and plugins currently uses int(dancer_version) to discover if it's running under Dancer 1 or Dancer 2.
int(1.0000_01) emits a warnings, so to work around that, a ne keyword has been added :
dancer_major_version, which returns what's on the left of the dot in the version number.
Fine, except that : - this keyword has not been added to Dancer v1, so plugins using dancer_major_version will break under Dancer 1 - no advertizing has been made on to what plugins should use (ie continue using int() or use the new keyword)
What's the best solution ?
In my opinion we can : 1/ Release a new Dancer 1, and ask people to use dancer_major_version and require the latest Dancer 1 release (or Dancer 2) : long and cumbersome as we need to potentially modify plugins and contact users and so all
2/ remove dancer_major_version, and change dancer_version so that it returns the version without the _xx at the end. Simple, doesn't need to release D1 again, and nothing to change in plugins.
3/ any idea ?
As you may guess, I'm a big fan of solution 2. If you all agree (especially sukria, as he added dancer_major_version, and maybe he had an other reasons for that), I can make the change.
In my opinion, the longer we stay in the current situation (dancer_major_version only in D2), the more dangerous it is
dams.
_______________________________________________ dancer-dev mailing list dancer-dev@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-dev
On Thu, 27 Dec 2012 12:46:20 +0100 Alexis Sukrieh <sukria@sukria.net> wrote:
Actually, the whole thing is that dancer_version (or major_version) should clearly not be used for plugins to check their compatibility with the core. Actually, what plugin should do is to use api_version.
Simple example :
Dancer 1.9999_01 is "Dancer 1" is you look at the VERSION (whatever method you choose) but it's actually "Dancer 2" regarding its core.
So to summarize:
- dancer_major_version should be removed, it has been added in a rush, while releasing 1.9999_01 but was a mistake because of the reason explained above - api_version should be used whenever something needs to check its compatibility with the core
I'm not sure; a lot of existing plugins use dancer_version, and it's meaning is fairly clear. I think the pragmatic approach is to let them continue to do so, with a couple of tweaks: - dancer_version can strip /_\d+$/ so that dev releases don't cause issues - a special-case for D2 - e.g. return 2 if ($version >= 1.9) - if the code is calling dancer_version, it most likely wants to know the difference between D1 and D2, I can't see that it's likely to be used in many other ways, you'd tend to use $Dancer::VERSION for that. If that's no good, a potential other solution, which may be a little voodish, is to return an object which uses overload to overload stringification and comparison, so if you use it as a string (if you wanted to output the current Dancer version) it gives you the full version (perhaps minus the _\d+$ from a dev release), but if you use it in a comparison (e.g. if (dancer_version >= 2), it Does The Right Thing). What do you think? Whatever we decide to do, if we do change the behaviour of dancer_version a little it should be documented clearly. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
2012/12/27 David Precious <davidp@preshweb.co.uk>
I'm not sure; a lot of existing plugins use dancer_version, and it's meaning is fairly clear.
I think the pragmatic approach is to let them continue to do so, with a couple of tweaks:
- dancer_version can strip /_\d+$/ so that dev releases don't cause issues - a special-case for D2 - e.g. return 2 if ($version >= 1.9) - if the code is calling dancer_version, it most likely wants to know the difference between D1 and D2, I can't see that it's likely to be used in many other ways, you'd tend to use $Dancer::VERSION for that.
Good point, I like that approach. Then we should remove api_version. I don't even know why it was introduced to be frank :)
Le jeudi 27 décembre 2012 à 13:40, David Precious a écrit :
On Thu, 27 Dec 2012 12:46:20 +0100 Alexis Sukrieh <sukria@sukria.net> wrote:
Actually, the whole thing is that dancer_version (or major_version) should clearly not be used for plugins to check their compatibility with the core. Actually, what plugin should do is to use api_version.
Simple example :
Dancer 1.9999_01 is "Dancer 1" is you look at the VERSION (whatever method you choose) but it's actually "Dancer 2" regarding its core.
So to summarize:
- dancer_major_version should be removed, it has been added in a rush, while releasing 1.9999_01 but was a mistake because of the reason explained above - api_version should be used whenever something needs to check its compatibility with the core
I'm not sure; a lot of existing plugins use dancer_version, and it's meaning is fairly clear.
I think the pragmatic approach is to let them continue to do so, with a couple of tweaks:
- dancer_version can strip /_\d+$/ so that dev releases don't cause issues - a special-case for D2 - e.g. return 2 if ($version >= 1.9) - if the code is calling dancer_version, it most likely wants to know the difference between D1 and D2, I can't see that it's likely to be used in many other ways, you'd tend to use $Dancer::VERSION for that.
Looks very close to my second proposal, so I'm all for it :)
If that's no good, a potential other solution, which may be a little voodish, is to return an object which uses overload to overload stringification and comparison, so if you use it as a string (if you wanted to output the current Dancer version) it gives you the full version (perhaps minus the _\d+$ from a dev release), but if you use it in a comparison (e.g. if (dancer_version >= 2), it Does The Right Thing).
What do you think?
Whatever we decide to do, if we do change the behaviour of dancer_version a little it should be documented clearly.
-- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
participants (6)
-
Alexis Sukrieh -
damien krotkine -
Damien Krotkine
-
David Golden -
David Precious -
Henk van Oers