[kepler-dev] how to distribute, upgrade, and support Ptolemy under 2.0?

[Christopher Brooks]

Hi Tim,

The usage cases looks good, it helps to have something concrete
to discuss.

I'm slightly confused about your use of the term "publish".

In my mind, a software product is made available in a
prerelease form (alpha, beta, release candidates) and then released.

For example, Ptolemy II 8.0 is available via svn, so does this mean
it is published?  Eventually, it will be released, which
means the source tree evolves very slowly after that,
with critical bug fixes only.  How does the module scheme support the
development of releases?

When a module is finalized, then it will be using a particular
revision or mostly unchanging branch of the kepler and ptII
repositories.

So, I guess where I'm confused is that there is no notion in the
use scenarios that describe how often version numbers are changed?

Maybe I'm missing it, but is there an obvious module that is the
current development head that is working with the heads of the
various repositories?

I'm somewhat opposed to having lots of branches added to the ptII
tree because it adds clutter.  Every module that uses Ptolemy II
should not need a branch.

It would be better to either require a particular revision
of the ptII repository or else require a stable version, such
as the 7.0 or 8.0.

Is it possible to later create a branch from a particular revision?
For example if a module uses r50000 and now the tree is at r60000,
can I go back and create a branch based on r50000 and make changes
that are based on the r50000 tree?

Hope this helps,

_Christopher



Timothy McPhillips wrote:
> Hi Christopher,
> 
> A while back I posted a proposal for how modules will be published, how 
> new versions of modules will be distributed and installed, and how 
> patches with bug-fixes to modules will be applied in Kepler 2.0:  
> 
> https://kepler-project.org/developers/teams/build/documentation/proposed-usage-scenarios-for-publishing-and-patching-kepler-modules
> 
> One aspect of the approach described above is that branches of modules 
> are maintained for each major and minor branch of published modules, so 
> that patches can be created for each such version in the future.   What 
> do you think about how Ptolemy could best fit into this scheme? 
> 
> Thanks for your thoughts!
> 
> Cheers,
> 
> Tim

-- 
Christopher Brooks (cxh at eecs berkeley edu) University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480