gpstk

Hello,

On October 22 we would like to form the GPSTk stable release 1.4. We've
set a goal to perform a release once a quarter, and alas a quarter has
almost passed since 1.3. We're trying to live up to "release early and
often."

This time we want to try using the branching feature of Subversion to
minimize  the testing and reviewing associated with making a stable
release. YOu may see some tests submitted as we try out this feature in
the next week or so. Also this time we'll be checking that all the apps we
thinks should make it in, do!  ;-)

Any feedback is welcome. Feel free to reply directly to me or to the list
regarding any ideas or concerns about the timing or scope of this release.

Best regards,

Ben

Hi all!

I think that deprecated classes should be removed after following a process like the following:

- Insert a warning in class' documentation stating that it will be deprecated.
- Wait for a couple GPSTk releases, and then remove the class.

Regarding the branching prior to a release, I think it is a good idea.

Best regards,

Dago

-- 


Dagoberto Salazar
Grupo de Astronomia y Geomatica (gAGE)
Universidad Politecnica de Catalunya (UPC)
Barcelona. Spain
E-mail: Dagoberto.Jose.Salazar@...

I'm a bright: Google Brights


----- Original message -----
From: R. Benjamin Harris  <pben@...>
To: gpstk-devel@...
Sent: Thu Oct 11 2007 03:12:02 PM CEST
Subject: [Gpstk-devel] Pending 1.4 release and deprecation
Hello folks,

Recently we reworked the EphemerisStore tree. Now the root is XvtStore, 
and the interfaces have changed. The new functionality is great, however 
it has been suggested that we provide a deprecated version of the old 
EphemerisStore tree. So my questions are:

1) Do you think we need to provide a deprecated functionality *in this 
case*?
2) Generally speaking, under what situations should the GPSTk provide 
deprecated functionality?
3) If we choose not to provide deprecation, then we force stable users 
to use old and unmaintained versions of the GPSTk. Should we then 
support maintaining (to some extent) old versions? This implies we use 
the branching feature of subversion.
4) If we choose to provide deprecated functionality, how do we cope with 
simultaneous versions of the same class?

Here is my take on these questions

1 and 2) I am not sure. It totally depends on the needs of the (perhaps 
silent) stable user base -- some of whom I hope are getting this email.
3) This would require we learn more Subversion mechanics, but would 
actually help make the release process more efficient. We wouldn't have 
to chase down new changes as they are added, testing them and inspecting 
them.
4) This could be done using a namespaces, but this would require code 
changes (though simple).

Regards,
Ben

-- 
R. BENJAMIN HARRIS             Space & Geophysics Laboratory
pben@...          Applied Research Laboratories
(512) 835-3116                 The University of Texas at Austin
Fax: (512) 835-3544            http://www.arlut.utexas.edu/


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Gpstk-devel mailing list
Gpstk-devel@...
https://lists.sourceforge.net/lists/listinfo/gpstk-devel

Hello folks,

Recently we reworked the EphemerisStore tree. Now the root is XvtStore, 
and the interfaces have changed. The new functionality is great, however 
it has been suggested that we provide a deprecated version of the old 
EphemerisStore tree. So my questions are:

1) Do you think we need to provide a deprecated functionality *in this 
case*?
2) Generally speaking, under what situations should the GPSTk provide 
deprecated functionality?
3) If we choose not to provide deprecation, then we force stable users 
to use old and unmaintained versions of the GPSTk. Should we then 
support maintaining (to some extent) old versions? This implies we use 
the branching feature of subversion.
4) If we choose to provide deprecated functionality, how do we cope with 
simultaneous versions of the same class?

Here is my take on these questions

1 and 2) I am not sure. It totally depends on the needs of the (perhaps 
silent) stable user base -- some of whom I hope are getting this email.
3) This would require we learn more Subversion mechanics, but would 
actually help make the release process more efficient. We wouldn't have 
to chase down new changes as they are added, testing them and inspecting 
them.
4) This could be done using a namespaces, but this would require code 
changes (though simple).

Regards,
Ben

-- 
R. BENJAMIN HARRIS             Space & Geophysics Laboratory
pben@...          Applied Research Laboratories
(512) 835-3116                 The University of Texas at Austin
Fax: (512) 835-3544            http://www.arlut.utexas.edu/