You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Xavier Hanin <xa...@gmail.com> on 2007/06/07 09:26:37 UTC
Release plan (was Re: Steps toward graduation)
On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
>
> [B] We have done one release in the incubator, but we have no current
> release plan. This is something that we need to discuss in a separate
> thread.
We need to discuss our release plan since this is one point required for
graduation, but also because it would be really nice for our user community
to better know where we intend to go.
Establishing a road map for an open source project where only volunteers are
involved is not easy, because we can't be sure of the time we (committers)
will be able to involve in the project. However, Here are some thoughts
about our roadmap.
First I think that it would really be nice if we could get graduated before
shipping our final 2.0 release. About the content, I think we need to
concentrate on code cleanup, bug fixing, and maven 2 compatibility. The
cache management issue is also the most voted issue and thus I think it
would really be nice to get it implemented for this 2.0 release.
According to the work involved, does a following road map make sense:
2.0-alpha-2
includes reviewed cache management + progress in code cleanup and bug fix,
API not stable yet
=> early july
2.0-beta-1
more bug fix and code cleanup, API almost stable, review of tutorials
=> late august
2.0-RC1
all major known bug fixed, code cleanup finished for its most important part
(including all removal of _), published API stable, tutorials and
documentation updated
=> late september
2.0-RCx
every two weeks, depending on the number of major bugs found
2.0 final
somewhere between october and november
With this schedule we would have approximately one year between Ivy
1.4.1and Ivy
2.0. This is long, but the migration to the ASF, code cleanup and some bug
fixes and improvement take time. Therefore this schedule seems to be
something achievable and reasonable.
WDYT?
Xavier
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: Release plan (was Re: Steps toward graduation)
Posted by Xavier Hanin <xa...@gmail.com>.
We talked about releasing an alpha 2 version early july, is it still
something we want to do? It could be a good sign of progress for our users,
and we have a pretty good number of fix and improvements to release it "as
is" (it's still an alpha).
What do you think? Shall I plan to cut a release this week and submit it to
the vote?
Xavier
On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > [B] We have done one release in the incubator, but we have no current
> > release plan. This is something that we need to discuss in a separate
> > thread.
>
>
> We need to discuss our release plan since this is one point required for
> graduation, but also because it would be really nice for our user community
> to better know where we intend to go.
>
> Establishing a road map for an open source project where only volunteers
> are involved is not easy, because we can't be sure of the time we
> (committers) will be able to involve in the project. However, Here are some
> thoughts about our roadmap.
>
> First I think that it would really be nice if we could get graduated
> before shipping our final 2.0 release. About the content, I think we need
> to concentrate on code cleanup, bug fixing, and maven 2 compatibility. The
> cache management issue is also the most voted issue and thus I think it
> would really be nice to get it implemented for this 2.0 release.
>
> According to the work involved, does a following road map make sense:
> 2.0-alpha-2
> includes reviewed cache management + progress in code cleanup and bug fix,
> API not stable yet
> => early july
>
> 2.0-beta-1
> more bug fix and code cleanup, API almost stable, review of tutorials
> => late august
>
> 2.0-RC1
> all major known bug fixed, code cleanup finished for its most important
> part (including all removal of _), published API stable, tutorials and
> documentation updated
> => late september
>
> 2.0-RCx
> every two weeks, depending on the number of major bugs found
>
> 2.0 final
> somewhere between october and november
>
> With this schedule we would have approximately one year between Ivy 1.4.1and Ivy
> 2.0. This is long, but the migration to the ASF, code cleanup and some bug
> fixes and improvement take time. Therefore this schedule seems to be
> something achievable and reasonable.
>
> WDYT?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
--
Xavier Hanin - Independent Java Consultant
Creator of Ivy, xooki and xoocode.org
More about me: http://xhab.blogspot.com/
Re: Release plan (was Re: Steps toward graduation)
Posted by Gilles Scokart <gs...@gmail.com>.
2007/6/18, Xavier Hanin <xa...@gmail.com>:
> On 6/18/07, Gilles Scokart <gs...@gmail.com> wrote:
> >
> > I agree with this :
> > 2.0-alpha-2 : (bug fix + code cleaning) early-july
> > 2.0-beta-1: (bug fix + code cleaning + tutorial) late august
> > 2.0-RC1 (all major bug fixed + code cleaned + tutorial/doc updated)
> > late septembre
> > 2.0-RCx (all major bug fixed) every 2 weeks
> > 2.0 final : october/november (why not exactly 1 year after the vote
> > that accepted ivy in the incubator project)
> >
> > However, I'm still thinking that we should give us more time before
> > publishing an API. I think we could draft it, collect feedback from
> > it, but not yet release it. My prefference would be to do a complete
> > API in a 3.0.
>
>
> I think it's a matter of words. I would like to get in the 2.0 version at
> least a statement saying what is considered public in the API, and thus for
> which we will maintain backward compatiblity in 2.x versions. Even if this
> is a very minimal scope. To get a clean and reviewed API, I think we agree
> that we'd need to call it a 3.0 version. So I see no problem with breaking
> even things we'd agree to say it's public in 2.0. But I think being able to
> at least run a resolve from the API with confidence of stability for
> the 2.xstream is not a huge work and would help some users.
>
I see your point. Having a 2.0 also usable as a library with a
minimal API would be nice. However, I'm not sure that offering
something and saying "it's minimal, and we already have in mind to
change it in 3.0" is a good idea. (I exagerate maybe a litle bit, but
that's the impression that I have).
What does the other people on this list think.
--
Gilles SCOKART
Re: Release plan (was Re: Steps toward graduation)
Posted by Gilles Scokart <gs...@gmail.com>.
2007/6/18, Xavier Hanin <xa...@gmail.com>:
> Anyway, when this is agreed, we should reflect that in Jira. I
> > propose to put all major bug scheduled for 2.0, and to create a
> > release "futur" for all other issue (or alternatively, we could close
> > them with a status "later"). Then, when we fiw an issue planned for
> > 2.0, we put it into the correct version 2.0-xxx.
>
>
> I agree we should reflect it in JIRA, but I'm not sure using a release
> "future" is a good idea. Isn't "unscheduled" good enough? IMO if we
> carefully review all issues to be sure the one targetted for 2.0 are
> assigned to 2.0, I think it's enough.
>
> Xavier
I moved all bug to the target 2.0. When fixing it, we can
progressivaly put them in 2.0-xxx. Note that I didn't reviewed all of
them. So some might actually be new features or enhancements that we
could/should delay to an other release.
--
Gilles SCOKART
Re: Release plan (was Re: Steps toward graduation)
Posted by Xavier Hanin <xa...@gmail.com>.
On 6/18/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> I agree with this :
> 2.0-alpha-2 : (bug fix + code cleaning) early-july
> 2.0-beta-1: (bug fix + code cleaning + tutorial) late august
> 2.0-RC1 (all major bug fixed + code cleaned + tutorial/doc updated)
> late septembre
> 2.0-RCx (all major bug fixed) every 2 weeks
> 2.0 final : october/november (why not exactly 1 year after the vote
> that accepted ivy in the incubator project)
>
> However, I'm still thinking that we should give us more time before
> publishing an API. I think we could draft it, collect feedback from
> it, but not yet release it. My prefference would be to do a complete
> API in a 3.0.
I think it's a matter of words. I would like to get in the 2.0 version at
least a statement saying what is considered public in the API, and thus for
which we will maintain backward compatiblity in 2.x versions. Even if this
is a very minimal scope. To get a clean and reviewed API, I think we agree
that we'd need to call it a 3.0 version. So I see no problem with breaking
even things we'd agree to say it's public in 2.0. But I think being able to
at least run a resolve from the API with confidence of stability for
the 2.xstream is not a huge work and would help some users.
And concerning the cache managment. I know it is a very asked
> features. However, it is not very clear for me what we want to
> deliver. Do we want to allow to configure what is cached where, do we
> want to put in place some policies (like in maven) or do we want to do
> more?
> So I don't know if it should be put in 2.0 or if a 2.1 would be better.
Yes, this is still not absolutely clear for me, so I agree that we may need
some more time or help. What we can do is plan this for 2.1, and if somebody
wants to contribute something earlier (including one of the committers), we
will discuss to see if it's worth including the changes in 2.0 or not.
Anyway, when this is agreed, we should reflect that in Jira. I
> propose to put all major bug scheduled for 2.0, and to create a
> release "futur" for all other issue (or alternatively, we could close
> them with a status "later"). Then, when we fiw an issue planned for
> 2.0, we put it into the correct version 2.0-xxx.
I agree we should reflect it in JIRA, but I'm not sure using a release
"future" is a good idea. Isn't "unscheduled" good enough? IMO if we
carefully review all issues to be sure the one targetted for 2.0 are
assigned to 2.0, I think it's enough.
Xavier
WDYT?
> Gilles
>
> 2007/6/7, Xavier Hanin <xa...@gmail.com>:
> > On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
> > >
> > > I'm not sure we should focus on the API so quickly. As said a few
> days
> > > ago,
> > > the API should not be 'published' yet. There are a lot of refactoring
> to
> > > do
> > > before we can reach a stable API. And that can not be done so
> quickly.
> > > (NB:
> > > By API I understand our java API, not the ant tasks). Also, we need
> to
> > > collect some input on what API services are required.
> >
> >
> > OK, I think I wasn't clear enough, sorry. By stable API I mean establish
> > what is and what is not considered as our published API, and ensure that
> > what is considered public is stable. Even if the published part of our
> Java
> > API is only one class for 2.0, I think we need to state it clearly.
> > FurthermoreI think it would be good to be able to at least resolve
> > dependencies with a stable and published API. This could help Ivy get
> > integrated in other tools.
> >
> > But that doesn't prevent a 2.0 release that focus on ant, command line
> and
> > > IvyDE interface.
> >
> >
> > IvyDE needs a Java API to Ivy, but since the two projects are developed
> by
> > the same persons so far we can easily cope with changes in the Java API.
> >
> > I think the integration with a maven repository is still very important.
> > > 2.0 must be "100% compatible with a maven repository".
> >
> >
> > Agreed, but I don't think a 100% compatibility is really possible. It's
> > still sometimes difficult to know exactly how to deal with dependencies
> to
> > behave the maven way. Until pretty recently the conflict resolution with
> > several modules at the same level was not predictable, for instance. So
> I'd
> > prefer targetting a 99.9% compatibility :-)
> >
> > Also the number of jira issues is a major 'issue'. 127 open issues is
> > > really too big I think. We should focus on reducing this
> number. Some
> > > can
> > > be delegated to a 2.1 version or a 3.0 version, but this number must
> be
> > > reduced.
> >
> >
> > I partly disagree. The number of open issues is not a bad sign. Having a
> > high number of feature request or improvement is a sign that the
> community
> > is interested in the development. But a project can't answer all the
> needs
> > and ideas of everybody. So having a 2.0 with a high number of open
> > improvement and new feature issues is not a problem IMHO.
> > OTOH the number of open bugs is something that needs to be carefully
> > addressed for the 2.0 release. We have currently 41 open bugs. And this
> is
> > too much for a final release, that's why I don't think targetting the
> > 2.0final too early would be a good thing. Targetting the first RC late
> > september seems reasonnable though (IMO).
> >
> > Finally, in term of roadmap, we should have some vague idea of where to
> go
> > > further in a 2.1 or 3.0. The direction that can be taken :
> > > - osgi integration
> > > - more integration with maven code (reuse maven library or being
> reused by
> > > maven).
> > > - Support of other type of repositories
> > > - Reusable API (becomes a dependency management library)
> > > - JSR xxxx compliance
> >
> >
> > IMO discussing a 3.0 is too early, because we are still too far away.
> > Discussing a 2.1 is more interesting IMO. But maybe we could try to
> first
> > agree on the 2.0 roadmap before discussing the rest?
> >
> > Xavier
> >
> > > -----Original Message-----
> > > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > > Sent: jeudi 7 juin 2007 11:27
> > > > To: ivy-dev@incubator.apache.org
> > > > Subject: Release plan (was Re: Steps toward graduation)
> > > >
> > > > On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > > >
> > > > > [B] We have done one release in the incubator, but we have no
> current
> > > > > release plan. This is something that we need to discuss in a
> separate
> > > > > thread.
> > > >
> > > >
> > > > We need to discuss our release plan since this is one point required
> for
> > > > graduation, but also because it would be really nice for our user
> > > > community
> > > > to better know where we intend to go.
> > > >
> > > > Establishing a road map for an open source project where only
> volunteers
> > > > are
> > > > involved is not easy, because we can't be sure of the time we
> > > (committers)
> > > > will be able to involve in the project. However, Here are some
> thoughts
> > > > about our roadmap.
> > > >
> > > > First I think that it would really be nice if we could get graduated
> > > > before
> > > > shipping our final 2.0 release. About the content, I think we need
> to
> > > > concentrate on code cleanup, bug fixing, and maven 2 compatibility.
> The
> > > > cache management issue is also the most voted issue and thus I think
> it
> > > > would really be nice to get it implemented for this 2.0 release.
> > > >
> > > > According to the work involved, does a following road map make
> sense:
> > > > 2.0-alpha-2
> > > > includes reviewed cache management + progress in code cleanup and
> bug
> > > fix,
> > > > API not stable yet
> > > > => early july
> > > >
> > > > 2.0-beta-1
> > > > more bug fix and code cleanup, API almost stable, review of
> tutorials
> > > > => late august
> > > >
> > > > 2.0-RC1
> > > > all major known bug fixed, code cleanup finished for its most
> important
> > > > part
> > > > (including all removal of _), published API stable, tutorials and
> > > > documentation updated
> > > > => late september
> > > >
> > > > 2.0-RCx
> > > > every two weeks, depending on the number of major bugs found
> > > >
> > > > 2.0 final
> > > > somewhere between october and november
> > > >
> > > > With this schedule we would have approximately one year between Ivy
> > > > 1.4.1and Ivy
> > > > 2.0. This is long, but the migration to the ASF, code cleanup and
> some
> > > bug
> > > > fixes and improvement take time. Therefore this schedule seems to be
> > > > something achievable and reasonable.
> > > >
> > > > WDYT?
> > > >
> > > > Xavier
> > > >
> > > > --
> > > > Xavier Hanin - Independent Java Consultant
> > > > Manage your dependencies with Ivy!
> > > > http://incubator.apache.org/ivy/
> > >
> > >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > Manage your dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
>
>
> --
> Gilles SCOKART
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
Re: Release plan (was Re: Steps toward graduation)
Posted by Gilles Scokart <gs...@gmail.com>.
I agree with this :
2.0-alpha-2 : (bug fix + code cleaning) early-july
2.0-beta-1: (bug fix + code cleaning + tutorial) late august
2.0-RC1 (all major bug fixed + code cleaned + tutorial/doc updated)
late septembre
2.0-RCx (all major bug fixed) every 2 weeks
2.0 final : october/november (why not exactly 1 year after the vote
that accepted ivy in the incubator project)
However, I'm still thinking that we should give us more time before
publishing an API. I think we could draft it, collect feedback from
it, but not yet release it. My prefference would be to do a complete
API in a 3.0.
And concerning the cache managment. I know it is a very asked
features. However, it is not very clear for me what we want to
deliver. Do we want to allow to configure what is cached where, do we
want to put in place some policies (like in maven) or do we want to do
more?
So I don't know if it should be put in 2.0 or if a 2.1 would be better.
Anyway, when this is agreed, we should reflect that in Jira. I
propose to put all major bug scheduled for 2.0, and to create a
release "futur" for all other issue (or alternatively, we could close
them with a status "later"). Then, when we fiw an issue planned for
2.0, we put it into the correct version 2.0-xxx.
WDYT?
Gilles
2007/6/7, Xavier Hanin <xa...@gmail.com>:
> On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
> >
> > I'm not sure we should focus on the API so quickly. As said a few days
> > ago,
> > the API should not be 'published' yet. There are a lot of refactoring to
> > do
> > before we can reach a stable API. And that can not be done so quickly.
> > (NB:
> > By API I understand our java API, not the ant tasks). Also, we need to
> > collect some input on what API services are required.
>
>
> OK, I think I wasn't clear enough, sorry. By stable API I mean establish
> what is and what is not considered as our published API, and ensure that
> what is considered public is stable. Even if the published part of our Java
> API is only one class for 2.0, I think we need to state it clearly.
> FurthermoreI think it would be good to be able to at least resolve
> dependencies with a stable and published API. This could help Ivy get
> integrated in other tools.
>
> But that doesn't prevent a 2.0 release that focus on ant, command line and
> > IvyDE interface.
>
>
> IvyDE needs a Java API to Ivy, but since the two projects are developed by
> the same persons so far we can easily cope with changes in the Java API.
>
> I think the integration with a maven repository is still very important.
> > 2.0 must be "100% compatible with a maven repository".
>
>
> Agreed, but I don't think a 100% compatibility is really possible. It's
> still sometimes difficult to know exactly how to deal with dependencies to
> behave the maven way. Until pretty recently the conflict resolution with
> several modules at the same level was not predictable, for instance. So I'd
> prefer targetting a 99.9% compatibility :-)
>
> Also the number of jira issues is a major 'issue'. 127 open issues is
> > really too big I think. We should focus on reducing this number. Some
> > can
> > be delegated to a 2.1 version or a 3.0 version, but this number must be
> > reduced.
>
>
> I partly disagree. The number of open issues is not a bad sign. Having a
> high number of feature request or improvement is a sign that the community
> is interested in the development. But a project can't answer all the needs
> and ideas of everybody. So having a 2.0 with a high number of open
> improvement and new feature issues is not a problem IMHO.
> OTOH the number of open bugs is something that needs to be carefully
> addressed for the 2.0 release. We have currently 41 open bugs. And this is
> too much for a final release, that's why I don't think targetting the
> 2.0final too early would be a good thing. Targetting the first RC late
> september seems reasonnable though (IMO).
>
> Finally, in term of roadmap, we should have some vague idea of where to go
> > further in a 2.1 or 3.0. The direction that can be taken :
> > - osgi integration
> > - more integration with maven code (reuse maven library or being reused by
> > maven).
> > - Support of other type of repositories
> > - Reusable API (becomes a dependency management library)
> > - JSR xxxx compliance
>
>
> IMO discussing a 3.0 is too early, because we are still too far away.
> Discussing a 2.1 is more interesting IMO. But maybe we could try to first
> agree on the 2.0 roadmap before discussing the rest?
>
> Xavier
>
> > -----Original Message-----
> > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > Sent: jeudi 7 juin 2007 11:27
> > > To: ivy-dev@incubator.apache.org
> > > Subject: Release plan (was Re: Steps toward graduation)
> > >
> > > On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
> > > >
> > > > [B] We have done one release in the incubator, but we have no current
> > > > release plan. This is something that we need to discuss in a separate
> > > > thread.
> > >
> > >
> > > We need to discuss our release plan since this is one point required for
> > > graduation, but also because it would be really nice for our user
> > > community
> > > to better know where we intend to go.
> > >
> > > Establishing a road map for an open source project where only volunteers
> > > are
> > > involved is not easy, because we can't be sure of the time we
> > (committers)
> > > will be able to involve in the project. However, Here are some thoughts
> > > about our roadmap.
> > >
> > > First I think that it would really be nice if we could get graduated
> > > before
> > > shipping our final 2.0 release. About the content, I think we need to
> > > concentrate on code cleanup, bug fixing, and maven 2 compatibility. The
> > > cache management issue is also the most voted issue and thus I think it
> > > would really be nice to get it implemented for this 2.0 release.
> > >
> > > According to the work involved, does a following road map make sense:
> > > 2.0-alpha-2
> > > includes reviewed cache management + progress in code cleanup and bug
> > fix,
> > > API not stable yet
> > > => early july
> > >
> > > 2.0-beta-1
> > > more bug fix and code cleanup, API almost stable, review of tutorials
> > > => late august
> > >
> > > 2.0-RC1
> > > all major known bug fixed, code cleanup finished for its most important
> > > part
> > > (including all removal of _), published API stable, tutorials and
> > > documentation updated
> > > => late september
> > >
> > > 2.0-RCx
> > > every two weeks, depending on the number of major bugs found
> > >
> > > 2.0 final
> > > somewhere between october and november
> > >
> > > With this schedule we would have approximately one year between Ivy
> > > 1.4.1and Ivy
> > > 2.0. This is long, but the migration to the ASF, code cleanup and some
> > bug
> > > fixes and improvement take time. Therefore this schedule seems to be
> > > something achievable and reasonable.
> > >
> > > WDYT?
> > >
> > > Xavier
> > >
> > > --
> > > Xavier Hanin - Independent Java Consultant
> > > Manage your dependencies with Ivy!
> > > http://incubator.apache.org/ivy/
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/
>
--
Gilles SCOKART
Re: Release plan (was Re: Steps toward graduation)
Posted by Xavier Hanin <xa...@gmail.com>.
On 6/7/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> I'm not sure we should focus on the API so quickly. As said a few days
> ago,
> the API should not be 'published' yet. There are a lot of refactoring to
> do
> before we can reach a stable API. And that can not be done so quickly.
> (NB:
> By API I understand our java API, not the ant tasks). Also, we need to
> collect some input on what API services are required.
OK, I think I wasn't clear enough, sorry. By stable API I mean establish
what is and what is not considered as our published API, and ensure that
what is considered public is stable. Even if the published part of our Java
API is only one class for 2.0, I think we need to state it clearly.
FurthermoreI think it would be good to be able to at least resolve
dependencies with a stable and published API. This could help Ivy get
integrated in other tools.
But that doesn't prevent a 2.0 release that focus on ant, command line and
> IvyDE interface.
IvyDE needs a Java API to Ivy, but since the two projects are developed by
the same persons so far we can easily cope with changes in the Java API.
I think the integration with a maven repository is still very important.
> 2.0 must be "100% compatible with a maven repository".
Agreed, but I don't think a 100% compatibility is really possible. It's
still sometimes difficult to know exactly how to deal with dependencies to
behave the maven way. Until pretty recently the conflict resolution with
several modules at the same level was not predictable, for instance. So I'd
prefer targetting a 99.9% compatibility :-)
Also the number of jira issues is a major 'issue'. 127 open issues is
> really too big I think. We should focus on reducing this number. Some
> can
> be delegated to a 2.1 version or a 3.0 version, but this number must be
> reduced.
I partly disagree. The number of open issues is not a bad sign. Having a
high number of feature request or improvement is a sign that the community
is interested in the development. But a project can't answer all the needs
and ideas of everybody. So having a 2.0 with a high number of open
improvement and new feature issues is not a problem IMHO.
OTOH the number of open bugs is something that needs to be carefully
addressed for the 2.0 release. We have currently 41 open bugs. And this is
too much for a final release, that's why I don't think targetting the
2.0final too early would be a good thing. Targetting the first RC late
september seems reasonnable though (IMO).
Finally, in term of roadmap, we should have some vague idea of where to go
> further in a 2.1 or 3.0. The direction that can be taken :
> - osgi integration
> - more integration with maven code (reuse maven library or being reused by
> maven).
> - Support of other type of repositories
> - Reusable API (becomes a dependency management library)
> - JSR xxxx compliance
IMO discussing a 3.0 is too early, because we are still too far away.
Discussing a 2.1 is more interesting IMO. But maybe we could try to first
agree on the 2.0 roadmap before discussing the rest?
Xavier
> -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: jeudi 7 juin 2007 11:27
> > To: ivy-dev@incubator.apache.org
> > Subject: Release plan (was Re: Steps toward graduation)
> >
> > On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
> > >
> > > [B] We have done one release in the incubator, but we have no current
> > > release plan. This is something that we need to discuss in a separate
> > > thread.
> >
> >
> > We need to discuss our release plan since this is one point required for
> > graduation, but also because it would be really nice for our user
> > community
> > to better know where we intend to go.
> >
> > Establishing a road map for an open source project where only volunteers
> > are
> > involved is not easy, because we can't be sure of the time we
> (committers)
> > will be able to involve in the project. However, Here are some thoughts
> > about our roadmap.
> >
> > First I think that it would really be nice if we could get graduated
> > before
> > shipping our final 2.0 release. About the content, I think we need to
> > concentrate on code cleanup, bug fixing, and maven 2 compatibility. The
> > cache management issue is also the most voted issue and thus I think it
> > would really be nice to get it implemented for this 2.0 release.
> >
> > According to the work involved, does a following road map make sense:
> > 2.0-alpha-2
> > includes reviewed cache management + progress in code cleanup and bug
> fix,
> > API not stable yet
> > => early july
> >
> > 2.0-beta-1
> > more bug fix and code cleanup, API almost stable, review of tutorials
> > => late august
> >
> > 2.0-RC1
> > all major known bug fixed, code cleanup finished for its most important
> > part
> > (including all removal of _), published API stable, tutorials and
> > documentation updated
> > => late september
> >
> > 2.0-RCx
> > every two weeks, depending on the number of major bugs found
> >
> > 2.0 final
> > somewhere between october and november
> >
> > With this schedule we would have approximately one year between Ivy
> > 1.4.1and Ivy
> > 2.0. This is long, but the migration to the ASF, code cleanup and some
> bug
> > fixes and improvement take time. Therefore this schedule seems to be
> > something achievable and reasonable.
> >
> > WDYT?
> >
> > Xavier
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > Manage your dependencies with Ivy!
> > http://incubator.apache.org/ivy/
>
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
RE: Release plan (was Re: Steps toward graduation)
Posted by Gilles Scokart <gs...@gmail.com>.
I'm not sure we should focus on the API so quickly. As said a few days ago,
the API should not be 'published' yet. There are a lot of refactoring to do
before we can reach a stable API. And that can not be done so quickly. (NB:
By API I understand our java API, not the ant tasks). Also, we need to
collect some input on what API services are required.
But that doesn't prevent a 2.0 release that focus on ant, command line and
IvyDE interface.
I think the integration with a maven repository is still very important.
2.0 must be "100% compatible with a maven repository".
Also the number of jira issues is a major 'issue'. 127 open issues is
really too big I think. We should focus on reducing this number. Some can
be delegated to a 2.1 version or a 3.0 version, but this number must be
reduced.
Finally, in term of roadmap, we should have some vague idea of where to go
further in a 2.1 or 3.0. The direction that can be taken :
- osgi integration
- more integration with maven code (reuse maven library or being reused by
maven).
- Support of other type of repositories
- Reusable API (becomes a dependency management library)
- JSR xxxx compliance
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: jeudi 7 juin 2007 11:27
> To: ivy-dev@incubator.apache.org
> Subject: Release plan (was Re: Steps toward graduation)
>
> On 6/7/07, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > [B] We have done one release in the incubator, but we have no current
> > release plan. This is something that we need to discuss in a separate
> > thread.
>
>
> We need to discuss our release plan since this is one point required for
> graduation, but also because it would be really nice for our user
> community
> to better know where we intend to go.
>
> Establishing a road map for an open source project where only volunteers
> are
> involved is not easy, because we can't be sure of the time we (committers)
> will be able to involve in the project. However, Here are some thoughts
> about our roadmap.
>
> First I think that it would really be nice if we could get graduated
> before
> shipping our final 2.0 release. About the content, I think we need to
> concentrate on code cleanup, bug fixing, and maven 2 compatibility. The
> cache management issue is also the most voted issue and thus I think it
> would really be nice to get it implemented for this 2.0 release.
>
> According to the work involved, does a following road map make sense:
> 2.0-alpha-2
> includes reviewed cache management + progress in code cleanup and bug fix,
> API not stable yet
> => early july
>
> 2.0-beta-1
> more bug fix and code cleanup, API almost stable, review of tutorials
> => late august
>
> 2.0-RC1
> all major known bug fixed, code cleanup finished for its most important
> part
> (including all removal of _), published API stable, tutorials and
> documentation updated
> => late september
>
> 2.0-RCx
> every two weeks, depending on the number of major bugs found
>
> 2.0 final
> somewhere between october and november
>
> With this schedule we would have approximately one year between Ivy
> 1.4.1and Ivy
> 2.0. This is long, but the migration to the ASF, code cleanup and some bug
> fixes and improvement take time. Therefore this schedule seems to be
> something achievable and reasonable.
>
> WDYT?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> Manage your dependencies with Ivy!
> http://incubator.apache.org/ivy/