Ivy - Proposal for reviving the project and moving towards a release

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Ivy - Proposal for reviving the project and moving towards a release

Jaikiran Pai
First off, I'm not an Ivy or Ant committer. The proposal that I make
below for an Ivy release is based on what was discussed in a recent mail
thread about the future of Ivy
https://www.mail-archive.com/dev@.../msg45078.html. There was
a suggestion that someone from community volunteer to try and bring in
some activity into the project and see if we can create a release after
triaging the JIRA issues.


I have had a look at the open issues in JIRA today and decided to filter
out issues that are open, updated since Jan 2014 and affects versions
2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to
just select a few that I thought can be considered "active". This [1]
returns 57 issues. I went ahead and looked at those issues today and
have asked for more information in the JIRAs wherever relevant and have
sent a couple of pull requests [2] [3] to fix some straightforward ones.
I also have another PR that I opened this week to fix one other issue.
Out of those 57 issues, many are no longer relevant or don't have enough
details. I don't have JIRA privileges to label them, share filters or
even assign some to myself to track them better. So I think for now, we
can rely on that JIRA search query [1].

At this point, I think, if we can target March 2017 for releasing a
2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
good start. Some of the issues noted in that JIRA are indeed important
ones and would need some review/help in fixing them correctly, which
essentially means, we need at least one person who has had experience
with the Ivy code and its design details and also has the committer rights.


Does any of this look feasible? Let me know if this isn't enough to move
things forward - I don't want to end up sending PRs and spending time on
this if there's no way we can get to a proper release in the next few
months.


[1]
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

[2] https://github.com/apache/ant-ivy/pull/11

[3] https://github.com/apache/ant-ivy/pull/12

-Jaikiran

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Matt Sicker
Do we really need a beta release? If you're working on bugfixes first, then
a regular 2.4.1 release would be great. It would go through the normal
Apache release candidate process, and perhaps we could get some Gradle
developers to test it out as well since they still seem to be big users of
Ivy.

Any committer to the Ant project could prepare the release and be a release
manager. The only requirements involving PMCs is to vote on approving the
release; adding your GPG key to the KEYS file (only PMCs can commit to that
repository involved); and committing the artifacts to the release svn
repository (again, PMCs). I'm also not a committer, but if you're
interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
bring you on board to do so.


On 11 December 2016 at 08:22, Jaikiran Pai <[hidden email]> wrote:

> First off, I'm not an Ivy or Ant committer. The proposal that I make below
> for an Ivy release is based on what was discussed in a recent mail thread
> about the future of Ivy https://www.mail-archive.com/d
> [hidden email]/msg45078.html. There was a suggestion that someone from
> community volunteer to try and bring in some activity into the project and
> see if we can create a release after triaging the JIRA issues.
>
>
> I have had a look at the open issues in JIRA today and decided to filter
> out issues that are open, updated since Jan 2014 and affects versions 2.1,
> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just select
> a few that I thought can be considered "active". This [1] returns 57
> issues. I went ahead and looked at those issues today and have asked for
> more information in the JIRAs wherever relevant and have sent a couple of
> pull requests [2] [3] to fix some straightforward ones. I also have another
> PR that I opened this week to fix one other issue. Out of those 57 issues,
> many are no longer relevant or don't have enough details. I don't have JIRA
> privileges to label them, share filters or even assign some to myself to
> track them better. So I think for now, we can rely on that JIRA search
> query [1].
>
> At this point, I think, if we can target March 2017 for releasing a
> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a good
> start. Some of the issues noted in that JIRA are indeed important ones and
> would need some review/help in fixing them correctly, which essentially
> means, we need at least one person who has had experience with the Ivy code
> and its design details and also has the committer rights.
>
>
> Does any of this look feasible? Let me know if this isn't enough to move
> things forward - I don't want to end up sending PRs and spending time on
> this if there's no way we can get to a proper release in the next few
> months.
>
>
> [1] <a href="https://issues.apache.org/jira/browse/IVY-1553?jql=project%">https://issues.apache.org/jira/browse/IVY-1553?jql=project%
> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>
> [2] https://github.com/apache/ant-ivy/pull/11
>
> [3] https://github.com/apache/ant-ivy/pull/12
>
> -Jaikiran
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Jaikiran Pai
I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
iron out any issues involved in the process itself which, from what I read
in the other thread, might involve certain challenges for the first time.

-Jaikiran

On Sunday, December 11, 2016, Matt Sicker <[hidden email]> wrote:
> Do we really need a beta release? If you're working on bugfixes first,
then
> a regular 2.4.1 release would be great. It would go through the normal
> Apache release candidate process, and perhaps we could get some Gradle
> developers to test it out as well since they still seem to be big users of
> Ivy.
>
> Any committer to the Ant project could prepare the release and be a
release
> manager. The only requirements involving PMCs is to vote on approving the
> release; adding your GPG key to the KEYS file (only PMCs can commit to
that
> repository involved); and committing the artifacts to the release svn
> repository (again, PMCs). I'm also not a committer, but if you're
> interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
> bring you on board to do so.
>
>
> On 11 December 2016 at 08:22, Jaikiran Pai <[hidden email]>
wrote:
>
>> First off, I'm not an Ivy or Ant committer. The proposal that I make
below
>> for an Ivy release is based on what was discussed in a recent mail thread
>> about the future of Ivy https://www.mail-archive.com/d
>> [hidden email]/msg45078.html. There was a suggestion that someone from
>> community volunteer to try and bring in some activity into the project
and
>> see if we can create a release after triaging the JIRA issues.
>>
>>
>> I have had a look at the open issues in JIRA today and decided to filter
>> out issues that are open, updated since Jan 2014 and affects versions
2.1,
>> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
select
>> a few that I thought can be considered "active". This [1] returns 57
>> issues. I went ahead and looked at those issues today and have asked for
>> more information in the JIRAs wherever relevant and have sent a couple of
>> pull requests [2] [3] to fix some straightforward ones. I also have
another
>> PR that I opened this week to fix one other issue. Out of those 57
issues,
>> many are no longer relevant or don't have enough details. I don't have
JIRA
>> privileges to label them, share filters or even assign some to myself to
>> track them better. So I think for now, we can rely on that JIRA search
>> query [1].
>>
>> At this point, I think, if we can target March 2017 for releasing a
>> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
good
>> start. Some of the issues noted in that JIRA are indeed important ones
and
>> would need some review/help in fixing them correctly, which essentially
>> means, we need at least one person who has had experience with the Ivy
code

>> and its design details and also has the committer rights.
>>
>>
>> Does any of this look feasible? Let me know if this isn't enough to move
>> things forward - I don't want to end up sending PRs and spending time on
>> this if there's no way we can get to a proper release in the next few
>> months.
>>
>>
>> [1] <a href="https://issues.apache.org/jira/browse/IVY-1553?jql=project%">https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>>
>> [2] https://github.com/apache/ant-ivy/pull/11
>>
>> [3] https://github.com/apache/ant-ivy/pull/12
>>
>> -Jaikiran
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Matt Sicker
Issues in the release process? Those would be handled by multiple release
candidates. People normally only use alphas and betas for new projects or
new major versions of projects at Apache.

On 11 December 2016 at 19:53, J Pai <[hidden email]> wrote:

> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
> iron out any issues involved in the process itself which, from what I read
> in the other thread, might involve certain challenges for the first time.
>
> -Jaikiran
>
> On Sunday, December 11, 2016, Matt Sicker <[hidden email]> wrote:
> > Do we really need a beta release? If you're working on bugfixes first,
> then
> > a regular 2.4.1 release would be great. It would go through the normal
> > Apache release candidate process, and perhaps we could get some Gradle
> > developers to test it out as well since they still seem to be big users
> of
> > Ivy.
> >
> > Any committer to the Ant project could prepare the release and be a
> release
> > manager. The only requirements involving PMCs is to vote on approving the
> > release; adding your GPG key to the KEYS file (only PMCs can commit to
> that
> > repository involved); and committing the artifacts to the release svn
> > repository (again, PMCs). I'm also not a committer, but if you're
> > interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
> > bring you on board to do so.
> >
> >
> > On 11 December 2016 at 08:22, Jaikiran Pai <[hidden email]>
> wrote:
> >
> >> First off, I'm not an Ivy or Ant committer. The proposal that I make
> below
> >> for an Ivy release is based on what was discussed in a recent mail
> thread
> >> about the future of Ivy https://www.mail-archive.com/d
> >> [hidden email]/msg45078.html. There was a suggestion that someone
> from
> >> community volunteer to try and bring in some activity into the project
> and
> >> see if we can create a release after triaging the JIRA issues.
> >>
> >>
> >> I have had a look at the open issues in JIRA today and decided to filter
> >> out issues that are open, updated since Jan 2014 and affects versions
> 2.1,
> >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
> select
> >> a few that I thought can be considered "active". This [1] returns 57
> >> issues. I went ahead and looked at those issues today and have asked for
> >> more information in the JIRAs wherever relevant and have sent a couple
> of
> >> pull requests [2] [3] to fix some straightforward ones. I also have
> another
> >> PR that I opened this week to fix one other issue. Out of those 57
> issues,
> >> many are no longer relevant or don't have enough details. I don't have
> JIRA
> >> privileges to label them, share filters or even assign some to myself to
> >> track them better. So I think for now, we can rely on that JIRA search
> >> query [1].
> >>
> >> At this point, I think, if we can target March 2017 for releasing a
> >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> good
> >> start. Some of the issues noted in that JIRA are indeed important ones
> and
> >> would need some review/help in fixing them correctly, which essentially
> >> means, we need at least one person who has had experience with the Ivy
> code
> >> and its design details and also has the committer rights.
> >>
> >>
> >> Does any of this look feasible? Let me know if this isn't enough to move
> >> things forward - I don't want to end up sending PRs and spending time on
> >> this if there's no way we can get to a proper release in the next few
> >> months.
> >>
> >>
> >> [1] <a href="https://issues.apache.org/jira/browse/IVY-1553?jql=project%">https://issues.apache.org/jira/browse/IVY-1553?jql=project%
> >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
> >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
> >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
> >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
> >>
> >> [2] https://github.com/apache/ant-ivy/pull/11
> >>
> >> [3] https://github.com/apache/ant-ivy/pull/12
> >>
> >> -Jaikiran
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Jaikiran Pai
Sounds fine then.

-Jaikiran

On Monday, December 12, 2016, Matt Sicker <[hidden email]> wrote:
> Issues in the release process? Those would be handled by multiple release
> candidates. People normally only use alphas and betas for new projects or
> new major versions of projects at Apache.
>
> On 11 December 2016 at 19:53, J Pai <[hidden email]> wrote:
>
>> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is
to
>> iron out any issues involved in the process itself which, from what I
read

>> in the other thread, might involve certain challenges for the first time.
>>
>> -Jaikiran
>>
>> On Sunday, December 11, 2016, Matt Sicker <[hidden email]> wrote:
>> > Do we really need a beta release? If you're working on bugfixes first,
>> then
>> > a regular 2.4.1 release would be great. It would go through the normal
>> > Apache release candidate process, and perhaps we could get some Gradle
>> > developers to test it out as well since they still seem to be big users
>> of
>> > Ivy.
>> >
>> > Any committer to the Ant project could prepare the release and be a
>> release
>> > manager. The only requirements involving PMCs is to vote on approving
the
>> > release; adding your GPG key to the KEYS file (only PMCs can commit to
>> that
>> > repository involved); and committing the artifacts to the release svn
>> > repository (again, PMCs). I'm also not a committer, but if you're
>> > interested enough in maintaining Ivy, I'd guess that the PMCs may wish
to

>> > bring you on board to do so.
>> >
>> >
>> > On 11 December 2016 at 08:22, Jaikiran Pai <[hidden email]>
>> wrote:
>> >
>> >> First off, I'm not an Ivy or Ant committer. The proposal that I make
>> below
>> >> for an Ivy release is based on what was discussed in a recent mail
>> thread
>> >> about the future of Ivy https://www.mail-archive.com/d
>> >> [hidden email]/msg45078.html. There was a suggestion that someone
>> from
>> >> community volunteer to try and bring in some activity into the project
>> and
>> >> see if we can create a release after triaging the JIRA issues.
>> >>
>> >>
>> >> I have had a look at the open issues in JIRA today and decided to
filter
>> >> out issues that are open, updated since Jan 2014 and affects versions
>> 2.1,
>> >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
>> select
>> >> a few that I thought can be considered "active". This [1] returns 57
>> >> issues. I went ahead and looked at those issues today and have asked
for
>> >> more information in the JIRAs wherever relevant and have sent a couple
>> of
>> >> pull requests [2] [3] to fix some straightforward ones. I also have
>> another
>> >> PR that I opened this week to fix one other issue. Out of those 57
>> issues,
>> >> many are no longer relevant or don't have enough details. I don't have
>> JIRA
>> >> privileges to label them, share filters or even assign some to myself
to
>> >> track them better. So I think for now, we can rely on that JIRA search
>> >> query [1].
>> >>
>> >> At this point, I think, if we can target March 2017 for releasing a
>> >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
>> good
>> >> start. Some of the issues noted in that JIRA are indeed important ones
>> and
>> >> would need some review/help in fixing them correctly, which
essentially
>> >> means, we need at least one person who has had experience with the Ivy
>> code
>> >> and its design details and also has the committer rights.
>> >>
>> >>
>> >> Does any of this look feasible? Let me know if this isn't enough to
move
>> >> things forward - I don't want to end up sending PRs and spending time
on

>> >> this if there's no way we can get to a proper release in the next few
>> >> months.
>> >>
>> >>
>> >> [1] <a href="https://issues.apache.org/jira/browse/IVY-1553?jql=project%">https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>> >>
>> >> [2] https://github.com/apache/ant-ivy/pull/11
>> >>
>> >> [3] https://github.com/apache/ant-ivy/pull/12
>> >>
>> >> -Jaikiran
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Sicker <[hidden email]>
>> >
>>
>
>
>
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Maarten Coene-2
In reply to this post by Jaikiran Pai
Thanks Jaikran,
I will look at your patches, I'll try to do it this week.If possible, please attach a junit test as well to reproduce the problem.

About the release, the master branch already contains some fixes since the 2.4.0 release. They are listed in the release-notes.html in the 'doc' directory. If we want to create a 2.4.1 release, we should merge all these changes (and all upcomming patches) into the 2.4.x branch as well. If we decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't pin on an exact timing, we can create a release any time when we think the codebase is ready for it.

We also have to find a release manager. I did it in the past when we were on SVN, but I don't have enough GIT knowledge (and I don't have the time to look into it) to do a new release.

Maarten

      Van: Jaikiran Pai <[hidden email]>
 Aan: [hidden email]
 Verzonden: zondag 11 december 15:22 2016
 Onderwerp: Ivy - Proposal for reviving the project and moving towards a release
   
First off, I'm not an Ivy or Ant committer. The proposal that I make
below for an Ivy release is based on what was discussed in a recent mail
thread about the future of Ivy
https://www.mail-archive.com/dev@.../msg45078.html. There was
a suggestion that someone from community volunteer to try and bring in
some activity into the project and see if we can create a release after
triaging the JIRA issues.


I have had a look at the open issues in JIRA today and decided to filter
out issues that are open, updated since Jan 2014 and affects versions
2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to
just select a few that I thought can be considered "active". This [1]
returns 57 issues. I went ahead and looked at those issues today and
have asked for more information in the JIRAs wherever relevant and have
sent a couple of pull requests [2] [3] to fix some straightforward ones.
I also have another PR that I opened this week to fix one other issue.
Out of those 57 issues, many are no longer relevant or don't have enough
details. I don't have JIRA privileges to label them, share filters or
even assign some to myself to track them better. So I think for now, we
can rely on that JIRA search query [1].

At this point, I think, if we can target March 2017 for releasing a
2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
good start. Some of the issues noted in that JIRA are indeed important
ones and would need some review/help in fixing them correctly, which
essentially means, we need at least one person who has had experience
with the Ivy code and its design details and also has the committer rights.


Does any of this look feasible? Let me know if this isn't enough to move
things forward - I don't want to end up sending PRs and spending time on
this if there's no way we can get to a proper release in the next few
months.


[1]
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

[2] https://github.com/apache/ant-ivy/pull/11

[3] https://github.com/apache/ant-ivy/pull/12

-Jaikiran

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



   
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Stefan Bodewig
On 2016-12-12, Maarten Coene wrote:

> We also have to find a release manager. I did it in the past when we
> were on SVN, but I don't have enough GIT knowledge (and I don't have
> the time to look into it) to do a new release.

Maarten, is this
<http://ant.apache.org/ivy/history/latest-milestone/dev/makerelease.html>
the guide you've been working from when you last cut a release?

It looks as if Nicolas had already converted it to use git commands
rather than svn. I'll be happy to proof-read the changes, but am pretty
certain they are correct.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Jaikiran Pai
In reply to this post by Maarten Coene-2
Maarten, thanks for volunteering to review the PRs. One of them has a test
case. I will add a test for the other one.

It looks like you have been involved with Ivy development and releases
before, so I think you would be in a better position to decide if it should
be 2.5.0 or 2.4.1. I personally prefer 2.4.1 because we are focussing on
fixing some reported issues rather than introducing some new features.

As for the release timeline, the reason I asked for a March 2017 date is to
make sure we have a realistic goal in mind of releasing it instead of a
open ended one which drags can potentially drag on for a while given the
current state of the project. Having said that, you and others in ant-dev
team who have been involved in previous releases can decide what makes
sense in terms of release commitments. My whole goal is to try and get a
usable bug fix release out soon, since the last one was 2 years back.

-Jaikiran

On Monday, December 12, 2016, Maarten Coene <[hidden email]>
wrote:
> Thanks Jaikran,
> I will look at your patches, I'll try to do it this week.If possible,
please attach a junit test as well to reproduce the problem.
>
> About the release, the master branch already contains some fixes since
the 2.4.0 release. They are listed in the release-notes.html in the 'doc'
directory. If we want to create a 2.4.1 release, we should merge all these
changes (and all upcomming patches) into the 2.4.x branch as well. If we
decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't
pin on an exact timing, we can create a release any time when we think the
codebase is ready for it.
>
> We also have to find a release manager. I did it in the past when we were
on SVN, but I don't have enough GIT knowledge (and I don't have the time to
look into it) to do a new release.
>
> Maarten
>
>       Van: Jaikiran Pai <[hidden email]>
>  Aan: [hidden email]
>  Verzonden: zondag 11 december 15:22 2016
>  Onderwerp: Ivy - Proposal for reviving the project and moving towards a
release

>
> First off, I'm not an Ivy or Ant committer. The proposal that I make
> below for an Ivy release is based on what was discussed in a recent mail
> thread about the future of Ivy
> https://www.mail-archive.com/dev@.../msg45078.html. There was
> a suggestion that someone from community volunteer to try and bring in
> some activity into the project and see if we can create a release after
> triaging the JIRA issues.
>
>
> I have had a look at the open issues in JIRA today and decided to filter
> out issues that are open, updated since Jan 2014 and affects versions
> 2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to
> just select a few that I thought can be considered "active". This [1]
> returns 57 issues. I went ahead and looked at those issues today and
> have asked for more information in the JIRAs wherever relevant and have
> sent a couple of pull requests [2] [3] to fix some straightforward ones.
> I also have another PR that I opened this week to fix one other issue.
> Out of those 57 issues, many are no longer relevant or don't have enough
> details. I don't have JIRA privileges to label them, share filters or
> even assign some to myself to track them better. So I think for now, we
> can rely on that JIRA search query [1].
>
> At this point, I think, if we can target March 2017 for releasing a
> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> good start. Some of the issues noted in that JIRA are indeed important
> ones and would need some review/help in fixing them correctly, which
> essentially means, we need at least one person who has had experience
> with the Ivy code and its design details and also has the committer
rights.

>
>
> Does any of this look feasible? Let me know if this isn't enough to move
> things forward - I don't want to end up sending PRs and spending time on
> this if there's no way we can get to a proper release in the next few
> months.
>
>
> [1]
>
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

>
> [2] https://github.com/apache/ant-ivy/pull/11
>
> [3] https://github.com/apache/ant-ivy/pull/12
>
> -Jaikiran
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Ivy - Proposal for reviving the project and moving towards a release

Oulds, Jonathan
I'd like to add my vote for a 2.4.1 release.  We don't want to raise the expectation that there will be substantial new functionality (which would warrant a 2.5.0 version).

However, if the 2.4.1 release goes well I would certainly suggest that we aim for a 2.5.0 release in the second half of 2017.

Longer term I would suggest that we try to maintain a regular release schedule ideally two per year as below:
Q1 - Bug fix:
Q3 - Bug fix plus at least one new feature:



Jonathan Oulds
Snr. Software Engineer
McAfee


-----Original Message-----
From: J Pai [mailto:[hidden email]]
Sent: Wednesday, December 14, 2016 4:11 AM
To: Ant Developers List <[hidden email]>; Maarten Coene <[hidden email]>
Subject: Re: Ivy - Proposal for reviving the project and moving towards a release

Maarten, thanks for volunteering to review the PRs. One of them has a test case. I will add a test for the other one.

It looks like you have been involved with Ivy development and releases before, so I think you would be in a better position to decide if it should be 2.5.0 or 2.4.1. I personally prefer 2.4.1 because we are focussing on fixing some reported issues rather than introducing some new features.

As for the release timeline, the reason I asked for a March 2017 date is to make sure we have a realistic goal in mind of releasing it instead of a open ended one which drags can potentially drag on for a while given the current state of the project. Having said that, you and others in ant-dev team who have been involved in previous releases can decide what makes sense in terms of release commitments. My whole goal is to try and get a usable bug fix release out soon, since the last one was 2 years back.

-Jaikiran

On Monday, December 12, 2016, Maarten Coene <[hidden email]>
wrote:
> Thanks Jaikran,
> I will look at your patches, I'll try to do it this week.If possible,
please attach a junit test as well to reproduce the problem.
>
> About the release, the master branch already contains some fixes since
the 2.4.0 release. They are listed in the release-notes.html in the 'doc'
directory. If we want to create a 2.4.1 release, we should merge all these changes (and all upcomming patches) into the 2.4.x branch as well. If we decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't pin on an exact timing, we can create a release any time when we think the codebase is ready for it.
>
> We also have to find a release manager. I did it in the past when we
> were
on SVN, but I don't have enough GIT knowledge (and I don't have the time to look into it) to do a new release.
>
> Maarten
>
>       Van: Jaikiran Pai <[hidden email]>
>  Aan: [hidden email]
>  Verzonden: zondag 11 december 15:22 2016
>  Onderwerp: Ivy - Proposal for reviving the project and moving towards
> a
release

>
> First off, I'm not an Ivy or Ant committer. The proposal that I make
> below for an Ivy release is based on what was discussed in a recent
> mail thread about the future of Ivy
> https://www.mail-archive.com/dev@.../msg45078.html. There
> was a suggestion that someone from community volunteer to try and
> bring in some activity into the project and see if we can create a
> release after triaging the JIRA issues.
>
>
> I have had a look at the open issues in JIRA today and decided to
> filter out issues that are open, updated since Jan 2014 and affects
> versions 2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter
> criteria to just select a few that I thought can be considered
> "active". This [1] returns 57 issues. I went ahead and looked at those
> issues today and have asked for more information in the JIRAs wherever
> relevant and have sent a couple of pull requests [2] [3] to fix some straightforward ones.
> I also have another PR that I opened this week to fix one other issue.
> Out of those 57 issues, many are no longer relevant or don't have
> enough details. I don't have JIRA privileges to label them, share
> filters or even assign some to myself to track them better. So I think
> for now, we can rely on that JIRA search query [1].
>
> At this point, I think, if we can target March 2017 for releasing a
> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> good start. Some of the issues noted in that JIRA are indeed important
> ones and would need some review/help in fixing them correctly, which
> essentially means, we need at least one person who has had experience
> with the Ivy code and its design details and also has the committer
rights.

>
>
> Does any of this look feasible? Let me know if this isn't enough to
> move things forward - I don't want to end up sending PRs and spending
> time on this if there's no way we can get to a proper release in the
> next few months.
>
>
> [1]
>
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

>
> [2] https://github.com/apache/ant-ivy/pull/11
>
> [3] https://github.com/apache/ant-ivy/pull/12
>
> -Jaikiran
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional
> commands, e-mail: [hidden email]
>
>
>
>
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Matt Sicker
When it comes to version numbers, I'm more concerned about following
semantic versioning than whether or not it's a major release. Bugfixes
warrant micro version updates, while new features warrant minor version
updates (and backward incompatible API changes are for the major version).

On 14 December 2016 at 05:47, Oulds, Jonathan <[hidden email]>
wrote:

> I'd like to add my vote for a 2.4.1 release.  We don't want to raise the
> expectation that there will be substantial new functionality (which would
> warrant a 2.5.0 version).
>
> However, if the 2.4.1 release goes well I would certainly suggest that we
> aim for a 2.5.0 release in the second half of 2017.
>
> Longer term I would suggest that we try to maintain a regular release
> schedule ideally two per year as below:
> Q1 - Bug fix:
> Q3 - Bug fix plus at least one new feature:
>
>
>
> Jonathan Oulds
> Snr. Software Engineer
> McAfee
>
>
> -----Original Message-----
> From: J Pai [mailto:[hidden email]]
> Sent: Wednesday, December 14, 2016 4:11 AM
> To: Ant Developers List <[hidden email]>; Maarten Coene <
> [hidden email]>
> Subject: Re: Ivy - Proposal for reviving the project and moving towards a
> release
>
> Maarten, thanks for volunteering to review the PRs. One of them has a test
> case. I will add a test for the other one.
>
> It looks like you have been involved with Ivy development and releases
> before, so I think you would be in a better position to decide if it should
> be 2.5.0 or 2.4.1. I personally prefer 2.4.1 because we are focussing on
> fixing some reported issues rather than introducing some new features.
>
> As for the release timeline, the reason I asked for a March 2017 date is
> to make sure we have a realistic goal in mind of releasing it instead of a
> open ended one which drags can potentially drag on for a while given the
> current state of the project. Having said that, you and others in ant-dev
> team who have been involved in previous releases can decide what makes
> sense in terms of release commitments. My whole goal is to try and get a
> usable bug fix release out soon, since the last one was 2 years back.
>
> -Jaikiran
>
> On Monday, December 12, 2016, Maarten Coene <[hidden email].
> invalid>
> wrote:
> > Thanks Jaikran,
> > I will look at your patches, I'll try to do it this week.If possible,
> please attach a junit test as well to reproduce the problem.
> >
> > About the release, the master branch already contains some fixes since
> the 2.4.0 release. They are listed in the release-notes.html in the 'doc'
> directory. If we want to create a 2.4.1 release, we should merge all these
> changes (and all upcomming patches) into the 2.4.x branch as well. If we
> decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't
> pin on an exact timing, we can create a release any time when we think the
> codebase is ready for it.
> >
> > We also have to find a release manager. I did it in the past when we
> > were
> on SVN, but I don't have enough GIT knowledge (and I don't have the time
> to look into it) to do a new release.
> >
> > Maarten
> >
> >       Van: Jaikiran Pai <[hidden email]>
> >  Aan: [hidden email]
> >  Verzonden: zondag 11 december 15:22 2016
> >  Onderwerp: Ivy - Proposal for reviving the project and moving towards
> > a
> release
> >
> > First off, I'm not an Ivy or Ant committer. The proposal that I make
> > below for an Ivy release is based on what was discussed in a recent
> > mail thread about the future of Ivy
> > https://www.mail-archive.com/dev@.../msg45078.html. There
> > was a suggestion that someone from community volunteer to try and
> > bring in some activity into the project and see if we can create a
> > release after triaging the JIRA issues.
> >
> >
> > I have had a look at the open issues in JIRA today and decided to
> > filter out issues that are open, updated since Jan 2014 and affects
> > versions 2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter
> > criteria to just select a few that I thought can be considered
> > "active". This [1] returns 57 issues. I went ahead and looked at those
> > issues today and have asked for more information in the JIRAs wherever
> > relevant and have sent a couple of pull requests [2] [3] to fix some
> straightforward ones.
> > I also have another PR that I opened this week to fix one other issue.
> > Out of those 57 issues, many are no longer relevant or don't have
> > enough details. I don't have JIRA privileges to label them, share
> > filters or even assign some to myself to track them better. So I think
> > for now, we can rely on that JIRA search query [1].
> >
> > At this point, I think, if we can target March 2017 for releasing a
> > 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> > good start. Some of the issues noted in that JIRA are indeed important
> > ones and would need some review/help in fixing them correctly, which
> > essentially means, we need at least one person who has had experience
> > with the Ivy code and its design details and also has the committer
> rights.
> >
> >
> > Does any of this look feasible? Let me know if this isn't enough to
> > move things forward - I don't want to end up sending PRs and spending
> > time on this if there's no way we can get to a proper release in the
> > next few months.
> >
> >
> > [1]
> >
> https://issues.apache.org/jira/browse/IVY-1553?jql=
> project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%
> 22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.
> 0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%
> 20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
> >
> > [2] https://github.com/apache/ant-ivy/pull/11
> >
> > [3] https://github.com/apache/ant-ivy/pull/12
> >
> > -Jaikiran
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For additional
> > commands, e-mail: [hidden email]
> >
> >
> >
> >
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Stefan Bodewig
On 2016-12-14, Matt Sicker wrote:

> When it comes to version numbers, I'm more concerned about following
> semantic versioning than whether or not it's a major release. Bugfixes
> warrant micro version updates, while new features warrant minor version
> updates (and backward incompatible API changes are for the major version).

I'm not sure how Ivy has decided on its version numbers in the past, but
for Ant we've never followed semantic versioning that strictly. In
particular we've created lots of micro releases that contained new
features and most of the time created minor versions when we changed JDK
requirements. In a sense we've shifted semantic versioning to the right
and never created major releases (and neither pure bugfix releases),
maybe because Ant2 could bring up some ghosts of the far past. :-)

As much as I like semantic versioning (and use it in other projects),
I'd prefer to stay consistent with the way versions have been used in
prior releases.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Matt Sicker
I'd definitely agree with the consistency principle.

On 15 December 2016 at 01:38, Stefan Bodewig <[hidden email]> wrote:

> On 2016-12-14, Matt Sicker wrote:
>
> > When it comes to version numbers, I'm more concerned about following
> > semantic versioning than whether or not it's a major release. Bugfixes
> > warrant micro version updates, while new features warrant minor version
> > updates (and backward incompatible API changes are for the major
> version).
>
> I'm not sure how Ivy has decided on its version numbers in the past, but
> for Ant we've never followed semantic versioning that strictly. In
> particular we've created lots of micro releases that contained new
> features and most of the time created minor versions when we changed JDK
> requirements. In a sense we've shifted semantic versioning to the right
> and never created major releases (and neither pure bugfix releases),
> maybe because Ant2 could bring up some ghosts of the far past. :-)
>
> As much as I like semantic versioning (and use it in other projects),
> I'd prefer to stay consistent with the way versions have been used in
> prior releases.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Gintautas Grigelionis
Is the version number agreed upon? For IvyDE builds think the latest
version of Ivy is 2.5.0.alpha_20161213000915

Gintas

2016-12-15 17:53 GMT+01:00 Matt Sicker <[hidden email]>:

> I'd definitely agree with the consistency principle.
>
> On 15 December 2016 at 01:38, Stefan Bodewig <[hidden email]> wrote:
>
> > On 2016-12-14, Matt Sicker wrote:
> >
> > > When it comes to version numbers, I'm more concerned about following
> > > semantic versioning than whether or not it's a major release. Bugfixes
> > > warrant micro version updates, while new features warrant minor version
> > > updates (and backward incompatible API changes are for the major
> > version).
> >
> > I'm not sure how Ivy has decided on its version numbers in the past, but
> > for Ant we've never followed semantic versioning that strictly. In
> > particular we've created lots of micro releases that contained new
> > features and most of the time created minor versions when we changed JDK
> > requirements. In a sense we've shifted semantic versioning to the right
> > and never created major releases (and neither pure bugfix releases),
> > maybe because Ant2 could bring up some ghosts of the far past. :-)
> >
> > As much as I like semantic versioning (and use it in other projects),
> > I'd prefer to stay consistent with the way versions have been used in
> > prior releases.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy - Proposal for reviving the project and moving towards a release

Gintautas Grigelionis
I was hit by https://issues.apache.org/jira/browse/IVY-1478 (updatesite
resolver sets ext token to empty rather than jar);
also, it seems illogical that jars directory in the cache contains jar.pack
files, whereas the actual jar files are in jars_unpacked...
anybody interested to discuss?

Gintas

2016-12-22 20:57 GMT+01:00 Gintautas Grigelionis <[hidden email]>:

> Is the version number agreed upon? For IvyDE builds think the latest
> version of Ivy is 2.5.0.alpha_20161213000915
>
> Gintas
>
>
> 2016-12-15 17:53 GMT+01:00 Matt Sicker <[hidden email]>:
>
>> I'd definitely agree with the consistency principle.
>>
>> On 15 December 2016 at 01:38, Stefan Bodewig <[hidden email]> wrote:
>>
>> > On 2016-12-14, Matt Sicker wrote:
>> >
>> > > When it comes to version numbers, I'm more concerned about following
>> > > semantic versioning than whether or not it's a major release. Bugfixes
>> > > warrant micro version updates, while new features warrant minor
>> version
>> > > updates (and backward incompatible API changes are for the major
>> > version).
>> >
>> > I'm not sure how Ivy has decided on its version numbers in the past, but
>> > for Ant we've never followed semantic versioning that strictly. In
>> > particular we've created lots of micro releases that contained new
>> > features and most of the time created minor versions when we changed JDK
>> > requirements. In a sense we've shifted semantic versioning to the right
>> > and never created major releases (and neither pure bugfix releases),
>> > maybe because Ant2 could bring up some ghosts of the far past. :-)
>> >
>> > As much as I like semantic versioning (and use it in other projects),
>> > I'd prefer to stay consistent with the way versions have been used in
>> > prior releases.
>> >
>> > Stefan
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> Matt Sicker <[hidden email]>
>>
>
>