Re: [geogig-dev] release schedule and version planning

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxxx>]

I also note that IT policies can take time to approve major version numbers (while dot releases have a shorter process).

I believe this restriction applies to GeoGig because we make a servlet available which could be installed in a webserver.

On Fri, Mar 18, 2016 at 2:47 PM, Jody Garnett <jgarnett@xxxxxxxxxxxxxxxx> wrote:

sign - let me try that again.

I gotta a confusion about our upcoming roadmap ... minor difference on numbering.

Java versioning:

- GeoGig 1.0 initial release (using BDB as default local repo)

- GeoGig 2.0 second release (using sqlite as default backend), locationtech approved dependencies

And dot release versioning:

- GeoGig 1.0 initial release (no default local repo, command line example of using BDB, sqlite)

- GeoGig 1.1 second release (BDB optional install, make sqlite the default) locationtech approved dependencies

Why worry: .. the whole product point of having an initial 1.0 release is to be STABLE so people trust us enough to embed geogig into EVERYTHING. If we follow it a few weeks-months later with a QGIS 2.0 we are sending a CRAZY signal to those wanting to use geogig - namely that we will never be stable enough to embed.

Talking with Tyler:  It is a bit rude having DBD as as default, and then having it be an optional install later. Update to 2.0 when the storage on disk changes and is incompatible, rather than based on any code changes

On Fri, Mar 18, 2016 at 2:45 PM, Gabriel Roldan <groldan@xxxxxxxxxxxxxxxx> wrote:

I concur it'd be crazy. Especially if you insist we call it QGIS instead of GeoGig :P

On Fri, Mar 18, 2016 at 6:37 PM, Jody Garnett <jgarnett@xxxxxxxxxxxxxxxx> wrote:

I gotta a confusion about our upcoming roadmap ... minor difference on numbering.

Java versioning:

- QGIS 1.0 initial release (using BDB as default local repo)

- QGIS 2.0 second release (using sqlite as default backend), locationtech approved dependencies

And dot release versioning:

- QGIS 1.0 initial release (no default local repo, command line example of using BDB, sqlite)

- QGIS 1.1 second release (BDB optional install, make sqlite the default) locationtech approved dependencies

Why worry: .. the whole product point of having an initial 1.0 release is to be STABLE so people trust us enough to embed geogig into EVERYTHING. If we follow it a few weeks-months later with a QGIS 2.0 we are sending a CRAZY signal to those wanting to use geogig - namely that we will never be stable enough to embed.

Talking with Tyler:  It is a bit rude having DBD as as default, and then having it be an optional install later. Update to 2.0 when the storage on disk changes and is incompatible, rather than based on any code changes.

-- 

Jody Garnett
Community Lead | Boundless

_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev

--

Gabriel Roldán
Software Developer | Boundless
groldan@xxxxxxxxxxxxxxxx
@boundlessgeo

_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev

--

--
Jody Garnett
Community Lead | Boundless

jgarnett@xxxxxxxxxxxxxxxx
@jodygarnett

--

--
Jody Garnett
Community Lead | Boundless
jgarnett@xxxxxxxxxxxxxxxx
@jodygarnett