commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <r...@evosent.com>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 18:19:55 GMT
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
>

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