commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 19:12:33 GMT
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


Mime
View raw message