commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 21:17:14 GMT
On 22 October 2013 22:10, sebb <sebbaz@gmail.com> wrote:
> 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?

Ignore that, I see that the package name has changed anyway.

>> 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
View raw message