ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Issue 10
Date Tue, 08 Aug 2006 17:08:35 GMT
Okay - I will submit a versioning design document to the Wiki for review.

Lance

On 8/8/06, Maciej Szefler <mbs@intalio.com> wrote:
>
> I think the versioning changes will require an understanding of how the
> feature would be implemented -- a design reveiew. As for the scratch vs
> patch, scratch is called for when multiple developers are going to be
> involved in developing a feature.
> -mbs
> On Tue, 2006-08-08 at 10:45 -0600, Lance Waterman wrote:
> > Okay - I'll create a separate versioning document.
> >
> > I do think the scope of the versioning changes warrants some type of
> review.
> > Are you suggesting that each developer creates a scratch area or perhaps
> a
> > scratch area for a JIRA issue that has a large scope?
> >
> > How do folks want to handle this ( patch vs scratch )? How do other
> Apache
> > projects handle this?
> >
> > Lance
> >
> > On 8/8/06, Alex Boisvert <boisvert@intalio.com> wrote:
> > >
> > > Lance Waterman wrote:
> > > > Will do. The current deployment spec does talk about the runtime
> > > > aspects of
> > > > versioning. From a documentation stand point do you think versioning
> > > > should
> > > > be broken out into a separate doc?
> > > Versioning often comes up on the top of the list of questions I get
> > > related to BPM, so from a user point of view I think it would be nice
> to
> > > have a separate document that introduces the concepts and presents the
> > > entire lifecycle picture, including deployment.
> > >
> > > > Note: Since this could be a pervasive change, I will submit a patch
> for
> > > > review prior to checking in.
> > > An idea: you could also create a temporary branch to make it easier to
> > > share, collaborate and merge/synchronize the code if you think the
> scope
> > > warrants it.
> > >
> > > alex
> > >
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message