commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 22:03:41 GMT



Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone

-------- Original message --------
From: sebb 
Date:10/22/2013 17:10 (GMT-05:00) 
To: Commons Users List 
Subject: Re: [imaging] Plan for 1.0.0 release 

On 22 October 2013 21:34, Gary Gregory <garydgregory@gmail.com> wrote:
> This might be too wacky but I thought I'd offer it up anyway.
>
> It looks like we are going to go with a 1.0 release from trunk RSN.
> We known 2.0 will break BC and will come in a o.a.c.imaging2 package.
> So, why not release 1.0 in a package o.a.c.imaging1?

This will break compatibility with 0.9.7.
I thought the idea was to release a compatible version?

Hm I thought 097 was in the old name space. 

G

> Gary
>
>
> On Tue, Oct 22, 2013 at 3:40 PM, Damjan Jovanovic <damjan@apache.org> wrote:
>
>> Wow, that's a really good idea!
>>
>> Yes it's feasible. If you'd like to write and commit a patch for it, feel
>> free.
>>
>> Damjan
>>
>> On Tue, Oct 22, 2013 at 9:23 PM, Matt Benson <gudnabrsam@gmail.com> wrote:
>> > If the API will be extensible, that's perhaps a different matter,
>> although
>> > in that case maybe the extensible part should be an interface implemented
>> > by ImageFormat's constants. In this case we could convert ImageFormat to
>> an
>> > enum now and still make the API extensible later on.
>> >
>> > Does this sound feasible?
>> >
>> > Matt
>> >
>> >
>> > On Tue, Oct 22, 2013 at 2:12 PM, Damjan Jovanovic <damjan@apache.org>
>> wrote:
>> >
>> >> I would like to avoid an enum there for later versions because I'd
>> >> like to make the API extensible with user-defined image formats, but
>> >> we can add it for 1.0.0.
>> >>
>> >> Damjan
>> >>
>> >> On Tue, Oct 22, 2013 at 9:00 PM, Matt Benson <gudnabrsam@gmail.com>
>> wrote:
>> >> > At some point I had had it in mind that ImageFormat should be
>> converted
>> >> to
>> >> > a proper enum type.  Can anyone offer any reasons this should not
be
>> >> done,
>> >> > particularly before 1.0.0?
>> >> >
>> >> > Matt
>> >> >
>> >> >
>> >> > On Tue, Oct 22, 2013 at 1:44 PM, Damjan Jovanovic <
>> damjan.jov@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Yes I agree, we might as well release trunk as 1.0.0. I am fixing
the
>> >> >> last few bugs in Jira, and then let's get started with the release
>> >> >> :-). Support would be appreciated.
>> >> >>
>> >> >> Damjan
>> >> >>
>> >> >> On Tue, Oct 22, 2013 at 8:19 PM, Raul Kripalani <raul@evosent.com>
>> >> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > @Gregory – many thanks for your input. You surely belong
very valid
>> >> >> points
>> >> >> > to the discussion.
>> >> >> >
>> >> >> > The issue I see is that Apache Sanselan 0.97 has such a wide
>> adoption
>> >> in
>> >> >> > the community that even in spite of the last public release
being
>> an
>> >> >> > Incubator one, it has earned itself the status of a de-facto
>> library
>> >> for
>> >> >> > image processing out there. It's quite mature and stable for
the
>> >> standard
>> >> >> > use cases. IMHO, release 0.97 has the status and bearing of
a
>> release
>> >> >> 1.0.0
>> >> >> > already.
>> >> >> >
>> >> >> > Want it or not, this means that you'll find yourself supporting
the
>> >> >> current
>> >> >> > API baseline for quite some time ;-) Bear in mind that the
Sanselan
>> >> use
>> >> >> > cases are typically quite static: once you've built your image
>> >> processing
>> >> >> > functionality into your app, it'll probably remain untouched
for a
>> >> long
>> >> >> > time. So the user has some functional changes to make in your
app,
>> >> they
>> >> >> > won't consider upgrading, let alone investing the effort to
adapt
>> >> their
>> >> >> > code to an entirely new API just for the sake of it.
>> >> >> >
>> >> >> > So, in a nutshell, it seems adequate to publish the current
trunk
>> as
>> >> >> > version 1.0.0, as folks are indeed already treating it as
such out
>> >> there.
>> >> >> >
>> >> >> > @Damjan – what's your take? I can support you these days
if you
>> >> decide to
>> >> >> > push out 1.0.0 now!
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > *Raúl Kripalani*
>> >> >> > Apache Camel PMC Member & Committer | Enterprise Architect,
Open
>> >> Source
>> >> >> > Integration specialist
>> >> >> > http://about.me/raulkripalani |
>> >> http://www.linkedin.com/in/raulkripalani
>> >> >> > http://blog.raulkr.net | twitter: @raulvk
>> >> >> >
>> >> >> > On Mon, Oct 21, 2013 at 5:23 PM, Gary Gregory <
>> garydgregory@gmail.com
>> >> >> >wrote:
>> >> >> >
>> >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory <
>> >> garydgregory@gmail.com
>> >> >> >> >wrote:
>> >> >> >>
>> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic
<
>> >> damjan@apache.org
>> >> >> >> >wrote:
>> >> >> >> >
>> >> >> >> >> Well as the only committer that's really working
on the
>> >> internals, I
>> >> >> >> >> am wondering what to do myself now.
>> >> >> >> >>
>> >> >> >> >> I've been working on (and have almost finished)
a very large
>> >> change
>> >> >> >> >> affecting virtually everything. When I commit
it, the API will
>> >> come
>> >> >> >> >> apart at the seams :-/, and people will not be
very happy with
>> the
>> >> >> >> >> rewrites of their own code they'll be doing.
>> >> >> >> >>
>> >> >> >> >> Which of the following would be best:
>> >> >> >> >> 1. Releasing what is in SVN trunk now (maybe
minus another API
>> >> >> >> >> breaking change from a few months ago) as 1.0,
then adding my
>> >> large
>> >> >> >> >> API-breaking change which will eventually be
released as
>> version
>> >> 2.0.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Remember that you'll have to change the package name
and Maven
>> >> >> >> coordinates
>> >> >> >> > for 2.0.
>> >> >> >> >
>> >> >> >>
>> >> >> >> The good news is that version 0.97 is in the old package
name
>> >> >> >> org.apache.sanselan. This means no jar hell for 1.0
>> >> >> >> (org.apache.commons.imaging) vs. 0.97. 1.0 which will
co-exist
>> with
>> >> >> 0.97 in
>> >> >> >> the same class loader. With option (1), upgrading from
0.97 to 1.0
>> >> will
>> >> >> >> mean AT LEAST updating all package imports, not that bad.
Make
>> sure
>> >> you
>> >> >> >> write good release notes ;)
>> >> >> >>
>> >> >> >> Let me also offer a bit of perspective for your consideration.
>> >> >> Releasing an
>> >> >> >> option (1) 1.0 means supporting it to some extent on the
ML and
>> with
>> >> >> >> possible maintenance releases. Since 2.0 is incompatible,
do you
>> >> really
>> >> >> >> want to take on maintaining two large code bases (or three
if you
>> >> count
>> >> >> >> 0.97)? Right now, there seems to be only one committer
with deep
>> >> domain
>> >> >> >> knowledge, you ;) Another possibility -- your (3) -- would
be to
>> >> "flush
>> >> >> >> out" another (last?) 0.x "release" to get trunk out there
for 0.x
>> >> users,
>> >> >> >> then release 1.0 which would be the new API. It seems
>> self-defeating
>> >> to
>> >> >> >> release a 1.0 knowing the API is not going to live going
forward
>> to
>> >> 2.0.
>> >> >> >> With option (2), you are saying, [imaging] has learned
its
>> lessons in
>> >> >> >> alpha, it has now grown up to a 1.0-level releasable API.
What I
>> do
>> >> not
>> >> >> >> know is how close you are to the new API being done.
>> >> >> >>
>> >> >> >> In the end, you know the audience best and users that
adopt a 0.x
>> >> >> product
>> >> >> >> should know that they are taking on a certain level of
risk. In
>> >> >> addition,
>> >> >> >> no one is forcing them to update to 1.0. Since you are
doing the
>> >> work,
>> >> >> I'll
>> >> >> >> support your efforts with option (1). If you called for
a [POLL]
>> >> email
>> >> >> on
>> >> >> >> the user's ML, my guess is that users would be happy with
a
>> >> non-breaking
>> >> >> >> 1.0 release.
>> >> >> >>
>> >> >> >> I know that our release process is painful, you might
have seen
>> >> >> discussions
>> >> >> >> about it recently, but keep on going, it seems we are
close.
>> >> >> >>
>> >> >> >> Gary
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> > Gary
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >> 2. Adding my large change now and API-breaking
everything in
>> >> trunk,
>> >> >> >> >> then releasing that as 1.0.
>> >> >> >> >> 3. Releasing what is in SVN trunk now (maybe
minus another API
>> >> >> >> >> breaking change from a few months ago) as 0.98,
then
>> API-breaking
>> >> >> >> >> everything, and then either releasing a 0.99
or 1.0. (This is
>> >> >> probably
>> >> >> >> >> the hardest option, and may not be possible,
since version
>> >> numbering
>> >> >> >> >> of nightly builds will go backwards and JIRA
bugs will need to
>> be
>> >> >> >> >> changed.)
>> >> >> >> >>
>> >> >> >> >> Thoughts? Preferences?
>> >> >> >> >>
>> >> >> >> >> Regards
>> >> >> >> >> Damjan
>> >> >> >> >>
>> >> >> >> >> On Mon, Oct 21, 2013 at 3:30 PM, Raul Kripalani
<
>> raul@evosent.com
>> >> >
>> >> >> >> wrote:
>> >> >> >> >> > Hello all,
>> >> >> >> >> >
>> >> >> >> >> > Are there any plans for releasing 1.0.0
soon?
>> >> >> >> >> >
>> >> >> >> >> > The last commit was 2 months old and the
community will
>> >> hands-down
>> >> >> >> >> benefit
>> >> >> >> >> > from a GA release that includes the bugfixes
and code renames
>> >> from
>> >> >> >> >> Sanselan
>> >> >> >> >> > to Commons Imaging, carried out ever since
0.9.7.
>> >> >> >> >> >
>> >> >> >> >> > Can I help in any way? We need the 1.0.0
release for our
>> >> project to
>> >> >> >> >> acquire
>> >> >> >> >> > the fix for IMAGING-49 [1], and we cannot
rely on SNAPSHOTs.
>> >> >> >> >> >
>> >> >> >> >> > [1] https://issues.apache.org/jira/browse/IMAGING-49
>> >> >> >> >> >
>> >> >> >> >> > Thanks,
>> >> >> >> >> >
>> >> >> >> >> > *Raúl Kripalani*
>> >> >> >> >> > Apache Camel PMC Member & Committer
| Enterprise Architect,
>> Open
>> >> >> >> Source
>> >> >> >> >> > Integration specialist
>> >> >> >> >> > http://about.me/raulkripalani |
>> >> >> >> >> http://www.linkedin.com/in/raulkripalani
>> >> >> >> >> > http://blog.raulkr.net | twitter: @raulvk
>> >> >> >> >>
>> >> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> >> >> >> >> For additional commands, e-mail: user-help@commons.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >> > Java Persistence with Hibernate, Second Edition<
>> >> >> >> http://www.manning.com/bauer3/>
>> >> >> >> > JUnit in Action, Second Edition <
>> http://www.manning.com/tahchiev/>
>> >> >> >> > Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> >> > Blog: http://garygregory.wordpress.com
>> >> >> >> > Home: http://garygregory.com/
>> >> >> >> > Tweet! http://twitter.com/GaryGregory
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> >> >> Java Persistence with Hibernate, Second Edition<
>> >> >> >> http://www.manning.com/bauer3/>
>> >> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
>> >
>> >> >> >> Spring Batch in Action <http://www.manning.com/templier/>
>> >> >> >> Blog: http://garygregory.wordpress.com
>> >> >> >> Home: http://garygregory.com/
>> >> >> >> Tweet! http://twitter.com/GaryGregory
>> >> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> >> >> For additional commands, e-mail: user-help@commons.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: user-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org

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