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 <garydgreg...@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 <dam...@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 <gudnabr...@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 <dam...@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 <gudnabr...@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....@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 <r...@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 <
>> garydgreg...@gmail.com
>> >> >> >wrote:
>> >> >> >
>> >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory <
>> >> garydgreg...@gmail.com
>> >> >> >> >wrote:
>> >> >> >>
>> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic <
>> >> dam...@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 <
>> r...@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-unsubscr...@commons.apache.org
>> >> >> >> >> For additional commands, e-mail: user-h...@commons.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org
>> >> >> For additional commands, e-mail: user-h...@commons.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: user-h...@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
