Quantcast

2.9.1 vs 2.10.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

2.9.1 vs 2.10.0

Dan Little-2
Hey folks,

Jim and I are working on some improvements to the 2.9 version of
GeoMoose.  I'm hoping to have something in the next month or so.  It
will feature:

* Various bug fixes as we find them.
* A slightly improved version of the Grid extension.
* Grid extension by default (maybe?)
* Some small improvements to the build system to make debugging easier.

Given the rules of semantic versioning I'm not sure where this falls.
The latter is definitely a change but it shouldn't be a breaking
change and would be very close to a "bug fix" IMO.  The bug being
"there are slow loading times for development".

Opinions?
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.9.1 vs 2.10.0

James Klassen-2
From semver.org

Given a version number MAJOR.MINOR.PATCH, increment the:
  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

=

I would vote for this being viewed from the users of our API's perspective, not the project's perspective.  The point of semantic versions is to communicate the level and type of change they can expect.  In our case our API is defined as the mapbook format, the javascript GeoMOOSE namespace, and the services interface.  Notable things that aren't listed that maybe should be might be general user experience (that would require retraining) and something covering the PHP services in the demo parcel application and maybe the layout of the demo.

To me the grid extension is (1) an extension, not core and (2) a bit of a technology preview as there are many known deficiencies yet particularly when dealing with more than one layer, so updates to that wouldn't force a 2.10 in my mind.

Changing the functional defaults (including the grid extension by default) may be going too far for a 2.9.1.

The rest seem to clearly fall into a 2.9.1.

Technically breaking changes should force a 3.0.



On Fri, Jun 10, 2016 at 11:09 AM, Dan Little <[hidden email]> wrote:
Hey folks,

Jim and I are working on some improvements to the 2.9 version of
GeoMoose.  I'm hoping to have something in the next month or so.  It
will feature:

* Various bug fixes as we find them.
* A slightly improved version of the Grid extension.
* Grid extension by default (maybe?)
* Some small improvements to the build system to make debugging easier.

Given the rules of semantic versioning I'm not sure where this falls.
The latter is definitely a change but it shouldn't be a breaking
change and would be very close to a "bug fix" IMO.  The bug being
"there are slow loading times for development".

Opinions?
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.9.1 vs 2.10.0

Eli Adam
On Fri, Jun 10, 2016 at 9:26 AM, James Klassen <[hidden email]> wrote:

> From semver.org
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner,
> and
> PATCH version when you make backwards-compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available as
> extensions to the MAJOR.MINOR.PATCH format.
>
> =
>
> I would vote for this being viewed from the users of our API's perspective,
> not the project's perspective.  The point of semantic versions is to

Exactly.  Build system and other development items have no impact on
the released software or versioning (from the users' perspective).

> communicate the level and type of change they can expect.  In our case our
> API is defined as the mapbook format, the javascript GeoMOOSE namespace, and
> the services interface.  Notable things that aren't listed that maybe should
> be might be general user experience (that would require retraining) and
> something covering the PHP services in the demo parcel application and maybe
> the layout of the demo.

Good point about the demo and default services.

>
> To me the grid extension is (1) an extension, not core and (2) a bit of a
> technology preview as there are many known deficiencies yet particularly
> when dealing with more than one layer, so updates to that wouldn't force a
> 2.10 in my mind.
>
> Changing the functional defaults (including the grid extension by default)
> may be going too far for a 2.9.1.

Right, this could go either way but is starting to push the limit.

>
> The rest seem to clearly fall into a 2.9.1.

Agree.

Eli

>
> Technically breaking changes should force a 3.0.
>
>
>
> On Fri, Jun 10, 2016 at 11:09 AM, Dan Little <[hidden email]>
> wrote:
>>
>> Hey folks,
>>
>> Jim and I are working on some improvements to the 2.9 version of
>> GeoMoose.  I'm hoping to have something in the next month or so.  It
>> will feature:
>>
>> * Various bug fixes as we find them.
>> * A slightly improved version of the Grid extension.
>> * Grid extension by default (maybe?)
>> * Some small improvements to the build system to make debugging easier.
>>
>> Given the rules of semantic versioning I'm not sure where this falls.
>> The latter is definitely a change but it shouldn't be a breaking
>> change and would be very close to a "bug fix" IMO.  The bug being
>> "there are slow loading times for development".
>>
>> Opinions?
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.9.1 vs 2.10.0

TC Haddad

Maybe you can better describe the 'grid extension by default' option, as that seems to be the pivotal issue?

- if 'default' means that it is included for easy access and use, that's fairly trivial
- if 'default' means that it is now going to displace an existing alternate method, that's significant.

TH

On Fri, Jun 10, 2016 at 9:49 AM, Eli Adam <[hidden email]> wrote:
On Fri, Jun 10, 2016 at 9:26 AM, James Klassen <[hidden email]> wrote:
> From semver.org
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner,
> and
> PATCH version when you make backwards-compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available as
> extensions to the MAJOR.MINOR.PATCH format.
>
> =
>
> I would vote for this being viewed from the users of our API's perspective,
> not the project's perspective.  The point of semantic versions is to

Exactly.  Build system and other development items have no impact on
the released software or versioning (from the users' perspective).

> communicate the level and type of change they can expect.  In our case our
> API is defined as the mapbook format, the javascript GeoMOOSE namespace, and
> the services interface.  Notable things that aren't listed that maybe should
> be might be general user experience (that would require retraining) and
> something covering the PHP services in the demo parcel application and maybe
> the layout of the demo.

Good point about the demo and default services.

>
> To me the grid extension is (1) an extension, not core and (2) a bit of a
> technology preview as there are many known deficiencies yet particularly
> when dealing with more than one layer, so updates to that wouldn't force a
> 2.10 in my mind.
>
> Changing the functional defaults (including the grid extension by default)
> may be going too far for a 2.9.1.

Right, this could go either way but is starting to push the limit.

>
> The rest seem to clearly fall into a 2.9.1.

Agree.

Eli

>
> Technically breaking changes should force a 3.0.
>
>
>
> On Fri, Jun 10, 2016 at 11:09 AM, Dan Little <[hidden email]>
> wrote:
>>
>> Hey folks,
>>
>> Jim and I are working on some improvements to the 2.9 version of
>> GeoMoose.  I'm hoping to have something in the next month or so.  It
>> will feature:
>>
>> * Various bug fixes as we find them.
>> * A slightly improved version of the Grid extension.
>> * Grid extension by default (maybe?)
>> * Some small improvements to the build system to make debugging easier.
>>
>> Given the rules of semantic versioning I'm not sure where this falls.
>> The latter is definitely a change but it shouldn't be a breaking
>> change and would be very close to a "bug fix" IMO.  The bug being
>> "there are slow loading times for development".
>>
>> Opinions?
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 2.9.1 vs 2.10.0

Dan Little-2
More the former than the later.  We have the grid. There is a lot of
demand to show off the grid functionality.  It's broken now, but it's
definitely going to be fixed soon.

I have a bias towards releasing a 2.9.1 to make it less intimidating looking.

On Fri, Jun 10, 2016 at 11:55 AM, TC Haddad <[hidden email]> wrote:

>
> Maybe you can better describe the 'grid extension by default' option, as
> that seems to be the pivotal issue?
>
> - if 'default' means that it is included for easy access and use, that's
> fairly trivial
> - if 'default' means that it is now going to displace an existing alternate
> method, that's significant.
>
> TH
>
> On Fri, Jun 10, 2016 at 9:49 AM, Eli Adam <[hidden email]> wrote:
>>
>> On Fri, Jun 10, 2016 at 9:26 AM, James Klassen <[hidden email]>
>> wrote:
>> > From semver.org
>> >
>> > Given a version number MAJOR.MINOR.PATCH, increment the:
>> >
>> > MAJOR version when you make incompatible API changes,
>> > MINOR version when you add functionality in a backwards-compatible
>> > manner,
>> > and
>> > PATCH version when you make backwards-compatible bug fixes.
>> >
>> > Additional labels for pre-release and build metadata are available as
>> > extensions to the MAJOR.MINOR.PATCH format.
>> >
>> > =
>> >
>> > I would vote for this being viewed from the users of our API's
>> > perspective,
>> > not the project's perspective.  The point of semantic versions is to
>>
>> Exactly.  Build system and other development items have no impact on
>> the released software or versioning (from the users' perspective).
>>
>> > communicate the level and type of change they can expect.  In our case
>> > our
>> > API is defined as the mapbook format, the javascript GeoMOOSE namespace,
>> > and
>> > the services interface.  Notable things that aren't listed that maybe
>> > should
>> > be might be general user experience (that would require retraining) and
>> > something covering the PHP services in the demo parcel application and
>> > maybe
>> > the layout of the demo.
>>
>> Good point about the demo and default services.
>>
>> >
>> > To me the grid extension is (1) an extension, not core and (2) a bit of
>> > a
>> > technology preview as there are many known deficiencies yet particularly
>> > when dealing with more than one layer, so updates to that wouldn't force
>> > a
>> > 2.10 in my mind.
>> >
>> > Changing the functional defaults (including the grid extension by
>> > default)
>> > may be going too far for a 2.9.1.
>>
>> Right, this could go either way but is starting to push the limit.
>>
>> >
>> > The rest seem to clearly fall into a 2.9.1.
>>
>> Agree.
>>
>> Eli
>>
>> >
>> > Technically breaking changes should force a 3.0.
>> >
>> >
>> >
>> > On Fri, Jun 10, 2016 at 11:09 AM, Dan Little <[hidden email]>
>> > wrote:
>> >>
>> >> Hey folks,
>> >>
>> >> Jim and I are working on some improvements to the 2.9 version of
>> >> GeoMoose.  I'm hoping to have something in the next month or so.  It
>> >> will feature:
>> >>
>> >> * Various bug fixes as we find them.
>> >> * A slightly improved version of the Grid extension.
>> >> * Grid extension by default (maybe?)
>> >> * Some small improvements to the build system to make debugging easier.
>> >>
>> >> Given the rules of semantic versioning I'm not sure where this falls.
>> >> The latter is definitely a change but it shouldn't be a breaking
>> >> change and would be very close to a "bug fix" IMO.  The bug being
>> >> "there are slow loading times for development".
>> >>
>> >> Opinions?
>> >> _______________________________________________
>> >> geomoose-psc mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>> >
>> >
>> >
>> > _______________________________________________
>> > geomoose-psc mailing list
>> > [hidden email]
>> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Loading...