Re: When to update version numbers?
I like the --force idea. I think we'll want that anyways for plugins that didn't write their tags right. On Wed, Sep 4, 2013 at 10:24 AM, Michal Mocny wrote: > I really don't want to have to be semantically valid for version > dependencies amongst contributors working on the bleeding edge on > unreleased branches. I'd be fine with just leaving the semantically > invalid engine values and make the dependency on "dev" implicit. However, > I would also support an explicit keyword like "dev", and then we are > semantically valid, yet still only worry about assigning concrete versions > id's at release time. > > -Michal > > > On Wed, Sep 4, 2013 at 9:56 AM, Ian Clelland > wrote: > > > I originally supported #1, because it makes development easier -- during > > development, if you add features, you can update cordova-core from > > "3.8-rc1" to "3.9-rc1", and then you can work on a corresponding plugin > > that declares a dependency on "3.9-rc1". > > > > Without doing this, you need to have your plugin syntactically depend on > > the latest *released* version of cordova (otherwise plugman will refuse > to > > install it), even though it only actually works with a recent development > > version. > > > > If we can either add a "--force" option to plugman to make it ignore > engine > > version requirements, or somehow special-case a version keyword like > "dev", > > so that it always installs, then I can get behind #2. > > > > Ian > > > > > > On Wed, Sep 4, 2013 at 6:10 AM, Shazron wrote: > > > > > +1 #2 > > > > > > > > > On Wed, Sep 4, 2013 at 3:24 AM, Joe Bowser wrote: > > > > > > > +1 for #2 > > > > > > > > On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI > > > wrote: > > > > > +1 for number 2 > > > > > > > > > > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp > > wrote: > > > > >> +1 for #2 as well > > > > >> > > > > >> > > > > >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson < > > > bra...@chromium.org > > > > >wrote: > > > > >> > > > > >>> +1 for #2. > > > > >>> > > > > >>> > > > > >>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny < > mmo...@chromium.org > > > > > > > wrote: > > > > >>> > > > > >>> > +1 for option #2 > > > > >>> > > > > > >>> > > > > > >>> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve < > > > agri...@chromium.org > > > > > > > > > >>> > wrote: > > > > >>> > > > > > >>> > > For repos that use SemVer, there are two options: > > > > >>> > > > > > > >>> > > 1. Update the version number at the time that the change is > > made > > > > >>> > > 2. Update the version number only when doing a release. > > > > >>> > > > > > > >>> > > Right now, #2 is what I've put in the wiki instructions, but > it > > > > can be > > > > >>> > > changed of course :) > > > > >>> > > > > > > >>> > > Two main reasons I think #2 will work better: > > > > >>> > > - #1 might be too complicated (might forget to update it, > may > > > > update > > > > >>> the > > > > >>> > > version multiple times if multiple feature changes go in) > > > > >>> > > - #2 If doing a release, you should know what you're > > releasing. > > > > Having > > > > >>> > to > > > > >>> > > choose the right version number will force you to understand > > what > > > > >>> you're > > > > >>> > > releasing. > > > > >>> > > > > > > >>> > > > > > >>> > > > > > > > > > >
Re: When to update version numbers?
I really don't want to have to be semantically valid for version dependencies amongst contributors working on the bleeding edge on unreleased branches. I'd be fine with just leaving the semantically invalid engine values and make the dependency on "dev" implicit. However, I would also support an explicit keyword like "dev", and then we are semantically valid, yet still only worry about assigning concrete versions id's at release time. -Michal On Wed, Sep 4, 2013 at 9:56 AM, Ian Clelland wrote: > I originally supported #1, because it makes development easier -- during > development, if you add features, you can update cordova-core from > "3.8-rc1" to "3.9-rc1", and then you can work on a corresponding plugin > that declares a dependency on "3.9-rc1". > > Without doing this, you need to have your plugin syntactically depend on > the latest *released* version of cordova (otherwise plugman will refuse to > install it), even though it only actually works with a recent development > version. > > If we can either add a "--force" option to plugman to make it ignore engine > version requirements, or somehow special-case a version keyword like "dev", > so that it always installs, then I can get behind #2. > > Ian > > > On Wed, Sep 4, 2013 at 6:10 AM, Shazron wrote: > > > +1 #2 > > > > > > On Wed, Sep 4, 2013 at 3:24 AM, Joe Bowser wrote: > > > > > +1 for #2 > > > > > > On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI > > wrote: > > > > +1 for number 2 > > > > > > > > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp > wrote: > > > >> +1 for #2 as well > > > >> > > > >> > > > >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson < > > bra...@chromium.org > > > >wrote: > > > >> > > > >>> +1 for #2. > > > >>> > > > >>> > > > >>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny > > > > wrote: > > > >>> > > > >>> > +1 for option #2 > > > >>> > > > > >>> > > > > >>> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve < > > agri...@chromium.org > > > > > > > >>> > wrote: > > > >>> > > > > >>> > > For repos that use SemVer, there are two options: > > > >>> > > > > > >>> > > 1. Update the version number at the time that the change is > made > > > >>> > > 2. Update the version number only when doing a release. > > > >>> > > > > > >>> > > Right now, #2 is what I've put in the wiki instructions, but it > > > can be > > > >>> > > changed of course :) > > > >>> > > > > > >>> > > Two main reasons I think #2 will work better: > > > >>> > > - #1 might be too complicated (might forget to update it, may > > > update > > > >>> the > > > >>> > > version multiple times if multiple feature changes go in) > > > >>> > > - #2 If doing a release, you should know what you're > releasing. > > > Having > > > >>> > to > > > >>> > > choose the right version number will force you to understand > what > > > >>> you're > > > >>> > > releasing. > > > >>> > > > > > >>> > > > > >>> > > > > > >
Re: When to update version numbers?
I originally supported #1, because it makes development easier -- during development, if you add features, you can update cordova-core from "3.8-rc1" to "3.9-rc1", and then you can work on a corresponding plugin that declares a dependency on "3.9-rc1". Without doing this, you need to have your plugin syntactically depend on the latest *released* version of cordova (otherwise plugman will refuse to install it), even though it only actually works with a recent development version. If we can either add a "--force" option to plugman to make it ignore engine version requirements, or somehow special-case a version keyword like "dev", so that it always installs, then I can get behind #2. Ian On Wed, Sep 4, 2013 at 6:10 AM, Shazron wrote: > +1 #2 > > > On Wed, Sep 4, 2013 at 3:24 AM, Joe Bowser wrote: > > > +1 for #2 > > > > On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI > wrote: > > > +1 for number 2 > > > > > > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote: > > >> +1 for #2 as well > > >> > > >> > > >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson < > bra...@chromium.org > > >wrote: > > >> > > >>> +1 for #2. > > >>> > > >>> > > >>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny > > wrote: > > >>> > > >>> > +1 for option #2 > > >>> > > > >>> > > > >>> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve < > agri...@chromium.org > > > > > >>> > wrote: > > >>> > > > >>> > > For repos that use SemVer, there are two options: > > >>> > > > > >>> > > 1. Update the version number at the time that the change is made > > >>> > > 2. Update the version number only when doing a release. > > >>> > > > > >>> > > Right now, #2 is what I've put in the wiki instructions, but it > > can be > > >>> > > changed of course :) > > >>> > > > > >>> > > Two main reasons I think #2 will work better: > > >>> > > - #1 might be too complicated (might forget to update it, may > > update > > >>> the > > >>> > > version multiple times if multiple feature changes go in) > > >>> > > - #2 If doing a release, you should know what you're releasing. > > Having > > >>> > to > > >>> > > choose the right version number will force you to understand what > > >>> you're > > >>> > > releasing. > > >>> > > > > >>> > > > >>> > > >
Re: When to update version numbers?
+1 #2 On Wed, Sep 4, 2013 at 3:24 AM, Joe Bowser wrote: > +1 for #2 > > On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI wrote: > > +1 for number 2 > > > > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote: > >> +1 for #2 as well > >> > >> > >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson >wrote: > >> > >>> +1 for #2. > >>> > >>> > >>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny > wrote: > >>> > >>> > +1 for option #2 > >>> > > >>> > > >>> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve > > >>> > wrote: > >>> > > >>> > > For repos that use SemVer, there are two options: > >>> > > > >>> > > 1. Update the version number at the time that the change is made > >>> > > 2. Update the version number only when doing a release. > >>> > > > >>> > > Right now, #2 is what I've put in the wiki instructions, but it > can be > >>> > > changed of course :) > >>> > > > >>> > > Two main reasons I think #2 will work better: > >>> > > - #1 might be too complicated (might forget to update it, may > update > >>> the > >>> > > version multiple times if multiple feature changes go in) > >>> > > - #2 If doing a release, you should know what you're releasing. > Having > >>> > to > >>> > > choose the right version number will force you to understand what > >>> you're > >>> > > releasing. > >>> > > > >>> > > >>> >
Re: When to update version numbers?
+1 for #2 On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI wrote: > +1 for number 2 > > On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote: >> +1 for #2 as well >> >> >> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson >> wrote: >> >>> +1 for #2. >>> >>> >>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote: >>> >>> > +1 for option #2 >>> > >>> > >>> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve >>> > wrote: >>> > >>> > > For repos that use SemVer, there are two options: >>> > > >>> > > 1. Update the version number at the time that the change is made >>> > > 2. Update the version number only when doing a release. >>> > > >>> > > Right now, #2 is what I've put in the wiki instructions, but it can be >>> > > changed of course :) >>> > > >>> > > Two main reasons I think #2 will work better: >>> > > - #1 might be too complicated (might forget to update it, may update >>> the >>> > > version multiple times if multiple feature changes go in) >>> > > - #2 If doing a release, you should know what you're releasing. Having >>> > to >>> > > choose the right version number will force you to understand what >>> you're >>> > > releasing. >>> > > >>> > >>>
Re: When to update version numbers?
+1 for number 2 On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote: > +1 for #2 as well > > > On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson wrote: > >> +1 for #2. >> >> >> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote: >> >> > +1 for option #2 >> > >> > >> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve >> > wrote: >> > >> > > For repos that use SemVer, there are two options: >> > > >> > > 1. Update the version number at the time that the change is made >> > > 2. Update the version number only when doing a release. >> > > >> > > Right now, #2 is what I've put in the wiki instructions, but it can be >> > > changed of course :) >> > > >> > > Two main reasons I think #2 will work better: >> > > - #1 might be too complicated (might forget to update it, may update >> the >> > > version multiple times if multiple feature changes go in) >> > > - #2 If doing a release, you should know what you're releasing. Having >> > to >> > > choose the right version number will force you to understand what >> you're >> > > releasing. >> > > >> > >>
Re: When to update version numbers?
+1 for #2 as well On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson wrote: > +1 for #2. > > > On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote: > > > +1 for option #2 > > > > > > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve > > wrote: > > > > > For repos that use SemVer, there are two options: > > > > > > 1. Update the version number at the time that the change is made > > > 2. Update the version number only when doing a release. > > > > > > Right now, #2 is what I've put in the wiki instructions, but it can be > > > changed of course :) > > > > > > Two main reasons I think #2 will work better: > > > - #1 might be too complicated (might forget to update it, may update > the > > > version multiple times if multiple feature changes go in) > > > - #2 If doing a release, you should know what you're releasing. Having > > to > > > choose the right version number will force you to understand what > you're > > > releasing. > > > > > >
Re: When to update version numbers?
+1 for #2. On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote: > +1 for option #2 > > > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve > wrote: > > > For repos that use SemVer, there are two options: > > > > 1. Update the version number at the time that the change is made > > 2. Update the version number only when doing a release. > > > > Right now, #2 is what I've put in the wiki instructions, but it can be > > changed of course :) > > > > Two main reasons I think #2 will work better: > > - #1 might be too complicated (might forget to update it, may update the > > version multiple times if multiple feature changes go in) > > - #2 If doing a release, you should know what you're releasing. Having > to > > choose the right version number will force you to understand what you're > > releasing. > > >
Re: When to update version numbers?
+1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve wrote: > For repos that use SemVer, there are two options: > > 1. Update the version number at the time that the change is made > 2. Update the version number only when doing a release. > > Right now, #2 is what I've put in the wiki instructions, but it can be > changed of course :) > > Two main reasons I think #2 will work better: > - #1 might be too complicated (might forget to update it, may update the > version multiple times if multiple feature changes go in) > - #2 If doing a release, you should know what you're releasing. Having to > choose the right version number will force you to understand what you're > releasing. >
When to update version numbers?
For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
