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 :

> 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 :
>
>> I'd definitely agree with the consistency principle.
>>
>> On 15 December 2016 at 01:38, Stefan Bodewig  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: dev-unsubscr...@ant.apache.org
>> > For additional commands, e-mail: dev-h...@ant.apache.org
>> >
>> >
>>
>>
>> --
>> Matt Sicker 
>>
>
>

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 :

> I'd definitely agree with the consistency principle.
>
> On 15 December 2016 at 01:38, Stefan Bodewig  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: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
>
> --
> Matt Sicker 
>

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  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: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Matt Sicker 

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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

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 
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:jai.forums2...@gmail.com]
> Sent: Wednesday, December 14, 2016 4:11 AM
> To: Ant Developers List ; Maarten Coene <
> maarten_co...@yahoo.com>
> 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  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 
> >  Aan: dev@ant.apache.org
> >  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@ant.apache.org/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
> > 

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:jai.forums2...@gmail.com] 
Sent: Wednesday, December 14, 2016 4:11 AM
To: Ant Developers List ; Maarten Coene 

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 
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 
>  Aan: dev@ant.apache.org
>  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@ant.apache.org/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]
>

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

[J Pai]

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 
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 
>  Aan: dev@ant.apache.org
>  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@ant.apache.org/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: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
>
>

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

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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

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

[Maarten Coene]

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 
 Aan: dev@ant.apache.org 
 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@ant.apache.org/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: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



   

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

[J Pai]

Sounds fine then.

-Jaikiran

On Monday, December 12, 2016, Matt Sicker  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  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  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 
>> 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
>> >> e...@ant.apache.org/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: dev-unsubscr...@ant.apache.org
>> >> For additional commands, e-mail: dev-h...@ant.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Sicker 
>> >
>>
>
>
>
> --
> Matt Sicker 
>

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  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  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 
> 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
> >> e...@ant.apache.org/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: dev-unsubscr...@ant.apache.org
> >> For additional commands, e-mail: dev-h...@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

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

[J 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  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 
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
>> e...@ant.apache.org/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: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
>
> --
> Matt Sicker 
>

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  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
> e...@ant.apache.org/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: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Matt Sicker