librelist archives

What's in our 1.0 release?

From:

Sebastian Benthall

Date:

2010-06-28 @ 19:06

David and I met last week to talk about what we would actually be releasing
for our upcoming 1.0 release.

We concluded that for the 1.0beta release, we would:
  * Tag the version in git
  * Make and publish a release bundle, along with deployment documentation (
like http://projects.opengeo.org/CAPRA/wiki/DeployingGeoNode )

For the official 1.0 release, we will see if we have time to use the
following additional release methods:
  * A "Pinax-style" system for installing GeoNode and providing an
environment for customization.  This already exists as part of the build,
but has the downside that it is currently totally custom.
  * A virtual machine image with GeoNode installed and configured properly
for easy installation.

We still have the long-term goal of switching over to a (literally)
Pinax-based system entirely, but we felt that there were too many unanswered
questions about how to package the JavaScript and Java dependencies within
that system to go for it as part of 1.0 work.  We'll bring those questions
back up on this list if one of you doesn't beat us to it.

Any questions? Objections? Comments?

-- 
Sebastian Benthall
OpenGeo - http://opengeo.org

I agree with all the points listed above.

But I wonder about PyPi, are we planning going to upload any kind of
artifacts there?

What would: `easy_install geonode`  (or pip install geonode) do if we did that?

Ariel.

On 06/28/2010 03:24 PM, Ariel Nunez wrote:
> I agree with all the points listed above.
>
> But I wonder about PyPi, are we planning going to upload any kind of
> artifacts there?
>
> What would: `easy_install geonode`  (or pip install geonode) do if we did that?
>
> Ariel.
>    
not very much. it does not include the static resources needed to run a 
geonode site, or geoserver or geonetwork. I am not sure providing 
geonode on pypi is going to be that useful since you will have to set up 
the other components by hand anyway.

I don't think that it's a bad idea to put geonode apps (like 
geonode.maps) on pypi, but I have the feeling that right now it's too 
tangled up for that to really make sense.  so maybe we could spawn off a 
thread on what a pypi-friendly geonode would look like.

-d

On 06/28/2010 03:24 PM, Ariel Nunez wrote:
> I agree with all the points listed above.
>
> But I wonder about PyPi, are we planning going to upload any kind of
> artifacts there?
>
> What would: `easy_install geonode`  (or pip install geonode) do if we did that?
>
> Ariel.
>    
not very much. it does not include the static resources needed to run a 
geonode site, or geoserver or geonetwork. I am not sure providing 
geonode on pypi is going to be that useful since you will have to set up 
the other components by hand anyway.

I don't think that it's a bad idea to put geonode apps (like 
geonode.maps) on pypi, but I have the feeling that right now it's too 
tangled up for that to really make sense.  so maybe we could spawn off a 
thread on what a pypi-friendly geonode would look like.

-d

On 6/28/10 4:06 PM, Sebastian Benthall wrote:
> David and I met last week to talk about what we would actually be releasing
> for our upcoming 1.0 release.
>
> We concluded that for the 1.0beta release, we would:
>    * Tag the version in git
>    * Make and publish a release bundle, along with deployment documentation (
> like http://projects.opengeo.org/CAPRA/wiki/DeployingGeoNode )
>
> For the official 1.0 release, we will see if we have time to use the
> following additional release methods:
>    * A "Pinax-style" system for installing GeoNode and providing an
> environment for customization.  This already exists as part of the build,
> but has the downside that it is currently totally custom.
>    * A virtual machine image with GeoNode installed and configured properly
> for easy installation.
an Amazon EC2 AMI?

will take less to register to amazon and launch the AMI than to download 
the VM image (at least at this side of the Ecuator)
>
> We still have the long-term goal of switching over to a (literally)
> Pinax-based system entirely, but we felt that there were too many unanswered
> questions about how to package the JavaScript and Java dependencies within
> that system to go for it as part of 1.0 work.  We'll bring those questions
> back up on this list if one of you doesn't beat us to it.
>
> Any questions? Objections? Comments?
>


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

> an Amazon EC2 AMI?
>
> will take less to register to amazon and launch the AMI than to download
> the VM image (at least at this side of the Ecuator)

Well, not everybody owns a credit card in this side of the Ecuator
(Barranquilla, 10 degrees north ;) ). But I also know that for many
"entities" the AMI approach would be better than the VM image one. So
my suggestion is to do both.

Ariel.

On 6/28/10 4:23 PM, Ariel Nunez wrote:
>> an Amazon EC2 AMI?
>>
>> will take less to register to amazon and launch the AMI than to download
>> the VM image (at least at this side of the Ecuator)
>
> Well, not everybody owns a credit card in this side of the Ecuator
> (Barranquilla, 10 degrees north ;) ). But I also know that for many
> "entities" the AMI approach would be better than the VM image one. So
> my suggestion is to do both.
good point :) . I meant to throw this as a complement to the VM image, 
sorry I wasn't clear.
Gabriel
>
> Ariel.


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.