commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [imaging] Plan for 1.0.0 release
Date Tue, 22 Oct 2013 20:34:21 GMT
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?

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

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