After a misunderstanding in the environments/development.yml I changed the value of "log" to log: "console" which is incorrect (as this value belongs to logger) but I have not seen any complaints about it. Shouldn't DAncer check if the config params are valid? BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well. Gabor -- Gabor Szabo http://szabgab.com/
On Tue, Dec 14, 2010 at 6:03 PM, Gabor Szabo <szabgab@gmail.com> wrote:
After a misunderstanding in the environments/development.yml I changed the value of "log" to
log: "console"
which is incorrect (as this value belongs to logger) but I have not seen any complaints about it.
Shouldn't DAncer check if the config params are valid?
Yes, this makes sense. For example, maybe there should be a warning if not grep config->{log} eq $_, qw(core, debug, warning, error).
BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well.
I don't agree with this. I put my own app specific params in the config. Like max_widgets: 100 -Naveed
Gabor
-- Gabor Szabo http://szabgab.com/ _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Tue, Dec 14, 2010 at 8:39 PM, Naveed Massjouni <naveedm9@gmail.com> wrote:
On Tue, Dec 14, 2010 at 6:03 PM, Gabor Szabo <szabgab@gmail.com> wrote:
After a misunderstanding in the environments/development.yml I changed the value of "log" to
log: "console"
which is incorrect (as this value belongs to logger) but I have not seen any complaints about it.
Shouldn't DAncer check if the config params are valid?
Yes, this makes sense. For example, maybe there should be a warning if not grep config->{log} eq $_, qw(core, debug, warning, error).
Ooops! I wrote bad syntax. Should be: if not grep config->{log} eq $_, qw(core debug warning error) You get the idea :) -Naveed
BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well.
I don't agree with this. I put my own app specific params in the config. Like max_widgets: 100
-Naveed
Gabor
-- Gabor Szabo http://szabgab.com/ _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Wed, Dec 15, 2010 at 3:39 AM, Naveed Massjouni <naveedm9@gmail.com> wrote:
On Tue, Dec 14, 2010 at 6:03 PM, Gabor Szabo <szabgab@gmail.com> wrote:
BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well.
I don't agree with this. I put my own app specific params in the config. Like max_widgets: 100
I have not reached the point yet to understand how I can add project specific params there but I would hope there is (or will be) some clear separation between the parameters that belong to various parts of the application. Name space for the config parameters? Otherwise how is it ensured that a future paramtername of Dancer or one of the plugins does not have the same name as the one in your application? In addition I hope there can be a way to let Dancer check the validity of your parameters as well e.g. by providing a declaration of accepted parameters, accepted values and default values to each parameter. Gabor http://szabgab.com/
*Top posted* Generally, you're suggesting a good feature. Having build-time checks of correct values/keys is important, but we still want to have users be able to provide their own keys and values. This is what helps make Dancer MVC-ish, because you can separate the view and model information in your configuration using any number of plugins or even in-house code for it. A possible solution would be to: 1. add a special key in the hash for user-defined information 2. allow the use to set their own keys/values in inner levels, thus never breaking non-existing plugins/engines. I would like to get more input on this from our architect, Sukria. On Wed, Dec 15, 2010 at 9:37 AM, Gabor Szabo <szabgab@gmail.com> wrote:
On Wed, Dec 15, 2010 at 3:39 AM, Naveed Massjouni <naveedm9@gmail.com> wrote:
On Tue, Dec 14, 2010 at 6:03 PM, Gabor Szabo <szabgab@gmail.com> wrote:
BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well.
I don't agree with this. I put my own app specific params in the config. Like max_widgets: 100
I have not reached the point yet to understand how I can add project specific params there but I would hope there is (or will be) some clear separation between the parameters that belong to various parts of the application. Name space for the config parameters?
Otherwise how is it ensured that a future paramtername of Dancer or one of the plugins does not have the same name as the one in your application?
In addition I hope there can be a way to let Dancer check the validity of your parameters as well e.g. by providing a declaration of accepted parameters, accepted values and default values to each parameter.
Gabor http://szabgab.com/ _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Hi, Le 15/12/2010 10:30, sawyer x a écrit :
Generally, you're suggesting a good feature. Having build-time checks of correct values/keys is important, but we still want to have users be able to provide their own keys and values.
Indeed, validating Dancer-native parameters is a good idea. We want to let the user use the config file for their personal use though.
This is what helps make Dancer MVC-ish, because you can separate the view and model information in your configuration using any number of plugins or even in-house code for it.
A possible solution would be to: 1. add a special key in the hash for user-defined information
I like the idea to introduce a "namespace" for user-defined parameters, but that would be hardly backward-compliant... We already have a "plugins" namespace and an "engine" one, so I suppose it definitely makes sense to add namespace, whose name would be the appname, for instance: # config.yml appname: "fooapp" logger: "console" ... plugins: .... engines: .... fooapp: some_user_defined_var: 42 ... Anything that is defined in the top-level would be considered Dancer's core property. This would allow for specific checks, and could protect users from using a key that would become Dancer-native in future versions. I like that idea, but my main concern here is backward-compat, as I said... -- Alexis Sukrieh
On Thu, Dec 16, 2010 at 8:06 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
This would allow for specific checks, and could protect users from using a key that would become Dancer-native in future versions.
I like that idea, but my main concern here is backward-compat, as I said...
You could start by adding warnings to everything that is not according to the definition and only in 3-4 months from now - if at all - turn them into fatal errors. Gabor
On Thu, Dec 16, 2010 at 8:45 PM, Gabor Szabo <szabgab@gmail.com> wrote:
On Thu, Dec 16, 2010 at 8:06 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
This would allow for specific checks, and could protect users from using
a
key that would become Dancer-native in future versions.
I like that idea, but my main concern here is backward-compat, as I said...
You could start by adding warnings to everything that is not according to the definition and only in 3-4 months from now - if at all - turn them into fatal errors.
Agreed, even if not using that time-frame. Our deprecation policy is to warn of deprecated behavior in the current release version in which it was deprecated (1.2x, 1.3x, whatever), and die fatally in a following major release. This could be added in Dancer 1.3x, including the deprecation warning. Then removed entirely in 1.4x. 1,2x was released only recently, so I'm not sure if we already want to deprecate stuff for the big chunk of users we now added (thanks to many marketing efforts by the entire community). Either way, there's no reason why not to start using this structure manually and implement the new strictures in a new branch to be merged on whichever release in which we want it. I'll try to get on it sometime soon. I still need to catch up on various new features - Sukria, Franck and Damien: I'm looking at you! :) Sawyer.
Le 16/12/2010 20:16, sawyer x a écrit :
Our deprecation policy is to warn of deprecated behavior in the current release version in which it was deprecated (1.2x, 1.3x, whatever), and die fatally in a following major release.
Indeed.
This could be added in Dancer 1.3x, including the deprecation warning. Then removed entirely in 1.4x.
I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds good. Making them fatal error in 1.4 makes sense. This strategy sounds good: release series with even number (1.2, 1.4, 1.6, ...) always contain stable features, intermediate series can deprecate things in the previous serie (1.3 can deprecate, with warnings, stuff in 1.2). I like that.
1,2x was released only recently, so I'm not sure if we already want to deprecate stuff for the big chunk of users we now added (thanks to many marketing efforts by the entire community).
As explained, I'd rather never deprecate anything in a stable serie, 1.2xxx is meant to provide bugfixes, documentation updates to the 1.2000 release, only. New features should be added to 1.3xxx in my opinion. And this is where deprecation can occur. So: 1.2xxx => stable codebase, no deprecation, no new features 1.3xxx => development codebase, deprecation, new features I welcome your points of view on this strategy. This also reminds me we need a new permanent branch on the repo, like experiemntal, where we will build releases for 1.3 I use such a layout at work, and it works pretty well (with git-flow configured in two different ways): 2.0000 -[ master ]------------------------------|-----------------------> -[ devel ]--+----------------------------+----------------------> \ / \-[ topic/XXXXX ]--------/ This layout is good for maintaining one release cycle, but if we want to provide development releases in parallel (1.3xxx) we need one more branch. Otherwise it will be veru difficult to maintain the 1.2 serie. So the layout could become somthing like this: 2.0000 -[ rel-stable ]-----------------------|-----------------------> -[ dev-stable ]--+----------------------------+----------------------> \ / \-[ topic/XXXXX ]--------/ 2.000 ... 3.0001 -[ rel-unstable ]-----------------|------------|-----------> -[ dev-unstable ]--+----------------------------+----------------------> \ / \-[ topic/XXXXX ]--------/ The rel- branches are used by git-flow to produce releases, the dev- ones are used as integration branches. My main concer is how can we publish those releases on CPAN...
Either way, there's no reason why not to start using this structure manually and implement the new strictures in a new branch to be merged on whichever release in which we want it. I'll try to get on it sometime soon.
Yes, that's another way of doing it, maybe more simple: use some parallel branches and merge them when we want, but I fear this will become very hard to maintain over time, if we want 1.2xxx to remain stable. Feel free to coment on that idea. Regards -- Alexis Sukrieh
On Fri, Dec 17, 2010 at 12:10 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds good. Making them fatal error in 1.4 makes sense.
This strategy sounds good: release series with even number (1.2, 1.4, 1.6, ...) always contain stable features, intermediate series can deprecate things in the previous serie (1.3 can deprecate, with warnings, stuff in 1.2).
The trick here is to get people to actually go through the 1.3 release branch or they will be not be able to transition easily. If they go through deprecating releases they'll get warnings on what to fix. If they don't, things will just break. This is the downside of it and usually why I don't support such behavior.
So:
1.2xxx => stable codebase, no deprecation, no new features 1.3xxx => development codebase, deprecation, new features
Like I said, the problem here is that people will generally prefer to avoid development branches, meaning that jumping from one stable release to the other (without the deprecation stage) will leave them broken. I suggest we start deprecating now. 1.2xxx => stable + deprecations 1.3xxx => new release, stable + breaking old deprecations That way we'll get people to definitely go over deprecations (when they stay within the certain branch, such as 1.2x). This means we'll also not confuse people with "development branch", "stable branch", etc. The important note here is that *deprecation is not breakage*. We are not breaking them, only reporting behavior which will be broken in a future release branch (such as 1.3x, or whichever the next one is).
This also reminds me we need a new permanent branch on the repo, like experiemntal, where we will build releases for 1.3
I use such a layout at work, and it works pretty well (with git-flow configured in two different ways):
2.0000 -[ master ]------------------------------|----------------------->
-[ devel ]--+----------------------------+----------------------> \ / \-[ topic/XXXXX ]--------/
This is what I use too and I find it very successful. We're going to start using it at $work as well.
This layout is good for maintaining one release cycle, but if we want to provide development releases in parallel (1.3xxx) we need one more branch. Otherwise it will be veru difficult to maintain the 1.2 serie.
I am personally against it. I don't want to start seeing multiple versions of things and start working on backporting features from here and there. This is a great pain to Linux distributions and it shouldn't be for us. My view is this: Every release series should have its own deprecations. Every release series can break a deprecation that appeared in a previous release series: 1.2x can break stuff that were deprecated in 1.1x. 1.3x can break stuff that were deprecated in 1.2x. There is no "development series" that people will prefer to overlook. Perl itself will not deprecate in a development and break in a stable. They will deprecate in the development, carry it to the stable (since the development is just a development track for the stable release) and then they will break it in a much futuristic version of the development which will become the next stable.
My main concer is how can we publish those releases on CPAN...
That's one of my main concerns. Another is how we manage it ourselves. It seems to me like a development and maintenance nightmare. Another concern is that people avoid using "development versions" and if that's the place where we deprecate, they won't even know it. All the best, Sawyer. :)
On Sat, Dec 18, 2010 at 11:48 AM, sawyer x <xsawyerx@gmail.com> wrote:
On Fri, Dec 17, 2010 at 12:10 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds good. Making them fatal error in 1.4 makes sense.
This strategy sounds good: release series with even number (1.2, 1.4, 1.6, ...) always contain stable features, intermediate series can deprecate things in the previous serie (1.3 can deprecate, with warnings, stuff in 1.2).
The trick here is to get people to actually go through the 1.3 release branch or they will be not be able to transition easily. If they go through deprecating releases they'll get warnings on what to fix. If they don't, things will just break.
This is the downside of it and usually why I don't support such behavior.
So:
1.2xxx => stable codebase, no deprecation, no new features 1.3xxx => development codebase, deprecation, new features
Like I said, the problem here is that people will generally prefer to avoid development branches, meaning that jumping from one stable release to the other (without the deprecation stage) will leave them broken.
I suggest we start deprecating now. 1.2xxx => stable + deprecations 1.3xxx => new release, stable + breaking old deprecations
In many projects even numbers represent stable version and odd numbers represent development version. So why not: 1.2 stable 1.3 development , warn for deprecations A 1.4 stable, warn for deprecations A 1.5 development , exception for deprecations A + warn for deprecation B 1.6 stable, exception for deprecations A + warn for deprecation B 1.7 development , exception for deprecations B + warn for deprecation C 1.8 stable, exception for deprecations B + warn for deprecation C Gabor
On Sat, Dec 18, 2010 at 1:41 PM, Gabor Szabo <szabgab@gmail.com> wrote:
In many projects even numbers represent stable version and odd numbers represent development version. So why not: 1.2 stable
1.3 development , warn for deprecations A 1.4 stable, warn for deprecations A
1.5 development , exception for deprecations A + warn for deprecation B 1.6 stable, exception for deprecations A + warn for deprecation B
1.7 development , exception for deprecations B + warn for deprecation C 1.8 stable, exception for deprecations B + warn for deprecation C
We already use _01, _02 and so on as development versions. I see it as an added tier and without good reason. Sawyer.
On 18/12/2010 13:13, sawyer x wrote:
In many projects even numbers represent stable version and odd numbers represent development version.
I agree with Gabor.
So why not: 1.2 stable
1.3 development , warn for deprecations A 1.4 stable, warn for deprecations A
1.5 development , exception for deprecations A + warn for deprecation B 1.6 stable, exception for deprecations A + warn for deprecation B
1.7 development , exception for deprecations B + warn for deprecation C 1.8 stable, exception for deprecations B + warn for deprecation C
We already use _01, _02 and so on as development versions.
Well no. We use XXX_XX releases as pre-releases of non-developer versions, just in order to make sure the test suite passes everywhere. So if we want the following to be true: "The entire 1.2xxx release series promises not to break your app, unless it is a critical fix (such as a security concern - which is business-critical). You are assured stability in upgrading to any 1.2xxx release." Then, we will HAVE to be able release both 1.200X_XX releases AND 1.3xx_XX releases. We cannot provide a 1.2 releases serie in parallel to a 1.3 one without forking the releases flows, I really don't see how we could... Please tell me if you have a magic solution I have not. I'd be happy to read it and to rethink my conclusions. We have IMHO two paths we can take: 1. We don't say that 1.2 will live as long as 1.3001 is out (and that makes the calendar lie); and we continue our workflow as always, with ONE release branch. And there, problem solved. 2. We want to do what is explained in the calendar, and allow users to stick with 1.2xx version until 1.4 is out for instance (I like very much that idea personnaly). But we have to provide then a new release cycle, for the reasons I explained in my previous mail (hotfix issues and so on, please read it if you didn't).
I see it as an added tier and without good reason.
Well, there is a reason you cant ignore: provinding a maintenance release series implies that you can do final and developer releases for that serie in parallel to the master serie. Again, all this situation is there because of what we said in the calendar, so either we choose to follow what we said, and we take conclusions on that, or we move a step back. But I really don't see how we could stay in the middle of this. Frankly. -- Alexis Sukrieh
On Thu, 2010-12-16 at 19:06 +0100, Alexis Sukrieh wrote:
We already have a "plugins" namespace and an "engine" one, so I suppose it definitely makes sense to add namespace, whose name would be the appname, for instance:
# config.yml appname: "fooapp" logger: "console" ...
plugins: .... engines: ....
fooapp: some_user_defined_var: 42 ...
Anything that is defined in the top-level would be considered Dancer's core property.
This would allow for specific checks, and could protect users from using a key that would become Dancer-native in future versions.
I like that idea, but my main concern here is backward-compat, as I said...
Personally, I like the simplicity of being able to shove your app's own config at the top level of the config file, and just say e.g. config->{foo} in your code. If we were having this discussion at the start of the project before anyone had started to use that, avoiding it could make sense, but I'm not sure I'd vote to deprecate it now. If we did decide to recommend that an app's own config settings go under 'appname' in the config, then I think we should have an app_config keyword which returns that, so you can say app_config->{foo} rather than config->{appname}{foo} (urgh, hardcoded appname) or config->{ config->{appname} }{foo} - neither of which are pretty. Cheers Dave P -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Tue, Feb 22, 2011 at 1:52 PM, David Precious <davidp@preshweb.co.uk>wrote:
Anything that is defined in the top-level would be considered Dancer's core property.
This would allow for specific checks, and could protect users from using a key that would become Dancer-native in future versions.
I like that idea, but my main concern here is backward-compat, as I said...
Personally, I like the simplicity of being able to shove your app's own config at the top level of the config file, and just say e.g. config->{foo} in your code.
I would propose to add a new configuration (a-la "strict") in order to decide whether top-level configurations are allowed or not. Then, it could be possible to set strict as default... or not, and let the user decide. Cheers, Flavio.
On Tue, 2011-02-22 at 12:52 +0000, David Precious wrote:
On Thu, 2010-12-16 at 19:06 +0100, Alexis Sukrieh wrote: [...]
Whoops, just realised I resurrected a very old thread there; my stupid mail client had jumped down to much older mails without me having realised :) Sorry about that. Seems it was something I missed at the time, though, so not all bad. -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
participants (6)
-
Alexis Sukrieh -
David Precious -
Flavio Poletti -
Gabor Szabo -
Naveed Massjouni -
sawyer x