Re: [commons-cli] How to handle deprecating options?

[Gary Gregory]

That sounds like a great feature to add to Commons CLI.

Gary

On Fri, Mar 22, 2024, 10:25 AM Eric Pugh 
wrote:

> We use commons-cli in Apache Solr, and we’re currently trying to
> standardize our mash-mash of command line arguments.   How do people handle
> deprecating an option in the Builder and introducing new ones?  Is there
> any techniques/features of commons-cli that support this use case?
>
> If you are curious, here is the current state of the work:
> https://github.com/apache/solr/pull/1768
>
> Eric
>
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> http://www.opensourceconnections.com <
> http://www.opensourceconnections.com/> | My Free/Busy <
> http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless of
> whether attachments are marked as such.
>
>

[commons-cli] How to handle deprecating options?

[Eric Pugh]

We use commons-cli in Apache Solr, and we’re currently trying to standardize 
our mash-mash of command line arguments.   How do people handle deprecating an 
option in the Builder and introducing new ones?  Is there any 
techniques/features of commons-cli that support this use case?

If you are curious, here is the current state of the work: 
https://github.com/apache/solr/pull/1768

Eric

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: RE: Re: release of commons-imaging

[Gary Gregory]

I'll see about creating a release candidate over the next few days.

Gary

On Fri, Mar 22, 2024, 6:07 AM William Borg Barthet <
william.borgbart...@bloomreach.com> wrote:

> Sorry to be a pain about this, is there any timeline for tagging/releasing
> a version of commons-imaging?
>
> Thanks again for your support.
>
> Regards,
>
> William
>
> On 2024/03/06 14:50:51 William Borg Barthet wrote:
> > Thanks for your replies.
> >
> > I am actually waiting on the WebP support. I found a PR and tested
> against
> > it and it seems to work for my purposes. I cannot really make use of a
> > SNAPSHOT, so any sort of tagged release, short of a 1.0 release would
> > suffice if it contained the WebP support.
> >
> > Thanks and regards
> >
> > William
> >
> > On 2024/02/28 15:43:06 Gary Gregory wrote:
> > > Yes: M is for milestone.
> > >
> > > Gary
> > >
> > > On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
> > > wrote:
> > >
> > > > >
> > > > > Why not continue with experimental releases using the same scheme
> > > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > > compatibility
> > > > > can be broken)?
> > > >
> > > >
> > > > Sounds good to me too, at least users wouldn't expect any difference
> > seeing
> > > > a new alphaN+1 announced. But not sure if there won't be any
> differences
> > > > with a milestone release (M is for milestone, right?)
> > > >
> > > > Cheers
> > > >
> > > > On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> > > > wrote:
> > > >
> > > > > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> > > > >  a écrit :
> > > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > What would be the main difference between the alpha and M1
> releases?
> > > > > >
> > > > > > I am not 100% confident that we have the public and protected API
> > > > right,
> > > > > > > specifically we might have too much public and protected. YMMV.
> > > > > >
> > > > > >
> > > > > > Agreed, and I think if we are to release anything, we would need
> > one or
> > > > > > more extra releases before we get everything right for the 1.0.
> But
> > if
> > > > we
> > > > > > can continue breaking backward compatibility (even though we will
> > try
> > > > > that
> > > > > > to only what's necessary to reduce impact to users) with
> M1/M2/M3,
> > the
> > > > > same
> > > > > > way we did with the alpha releases, then I'm +1 for that already.
> > > > >
> > > > > Why not continue with experimental releases using the same scheme
> > > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > > compatibility
> > > > > can be broken)?
> > > > >
> > > > > > > > [...]
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

RE: RE: Re: release of commons-imaging

[William Borg Barthet]

Sorry to be a pain about this, is there any timeline for tagging/releasing
a version of commons-imaging?

Thanks again for your support.

Regards,

William

On 2024/03/06 14:50:51 William Borg Barthet wrote:
> Thanks for your replies.
>
> I am actually waiting on the WebP support. I found a PR and tested against
> it and it seems to work for my purposes. I cannot really make use of a
> SNAPSHOT, so any sort of tagged release, short of a 1.0 release would
> suffice if it contained the WebP support.
>
> Thanks and regards
>
> William
>
> On 2024/02/28 15:43:06 Gary Gregory wrote:
> > Yes: M is for milestone.
> >
> > Gary
> >
> > On Wed, Feb 28, 2024, 10:40 AM Bruno Kinoshita 
> > wrote:
> >
> > > >
> > > > Why not continue with experimental releases using the same scheme
> > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > compatibility
> > > > can be broken)?
> > >
> > >
> > > Sounds good to me too, at least users wouldn't expect any difference
> seeing
> > > a new alphaN+1 announced. But not sure if there won't be any
differences
> > > with a milestone release (M is for milestone, right?)
> > >
> > > Cheers
> > >
> > > On Wed, 28 Feb 2024 at 16:11, Gilles Sadowski 
> > > wrote:
> > >
> > > > Le mer. 28 févr. 2024 à 16:00, Bruno Kinoshita
> > > >  a écrit :
> > > > >
> > > > > Hi Gary,
> > > > >
> > > > > What would be the main difference between the alpha and M1
releases?
> > > > >
> > > > > I am not 100% confident that we have the public and protected API
> > > right,
> > > > > > specifically we might have too much public and protected. YMMV.
> > > > >
> > > > >
> > > > > Agreed, and I think if we are to release anything, we would need
> one or
> > > > > more extra releases before we get everything right for the 1.0.
But
> if
> > > we
> > > > > can continue breaking backward compatibility (even though we will
> try
> > > > that
> > > > > to only what's necessary to reduce impact to users) with M1/M2/M3,
> the
> > > > same
> > > > > way we did with the alpha releases, then I'm +1 for that already.
> > > >
> > > > Why not continue with experimental releases using the same scheme
> > > > (i.e. "alpha", then "beta") with the agreed on semantics (that
> > > > compatibility
> > > > can be broken)?
> > > >
> > > > > > > [...]
> > > >
> > > >
-
> > > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: user-h...@commons.apache.org
> > > >
> > > >
> > >
> >
>