commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 21:16:20 GMT
I thought we had been discussing possibly adding some breaking changes for
1.0.0.  That said, I would personally be -0 to "imaging1", though I have to
skin in the game.

Matt


On Tue, Oct 22, 2013 at 4:10 PM, 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?
>
> > 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