|
Replies:
26
-
Last Post:
Mar 19, 2009 8:35 AM
by: kschaefe
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
Making 0.9.6 an API-breaking release
Posted:
Jan 6, 2009 10:44 AM
|
|
|
After a release with no API breaks, I would like to make 0.9.6 an API-breaking release. We have several tasks/bugs that require breaks and should be completed before 1.0. Most notable is task 903 (rename abstract classes to AbstractXXX).
Is there any objection to making 0.9.6 an API-breaking release?
Regardless, per our conventions anything deprecated before 0.9.5 will be removed in 0.9.6.
Karl
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Jan 9, 2009 4:03 AM
in response to: kschaefe
|
|
|
jdnc-interest@javadesktop.org schrieb:
> After a release with no API breaks, I would like to make 0.9.6 an API-breaking release. We have several tasks/bugs that require breaks and should be completed before 1.0. Most notable is task 903 (rename abstract classes to AbstractXXX).
>
dooohhh ... thought we had all ...
> Is there any objection to making 0.9.6 an API-breaking release?
>
yeah, I would prefer to not have a 0.9.6 at all but go all the way to
final right now  Open Cleanup issues are not such a big deal because
after final will break everything anyway.
> Regardless, per our conventions anything deprecated before 0.9.5 will be removed in 0.9.6.
>
agreed - anybody already tagged them for removal? (available for removal
are those with a pre-0.9.5 marker). Silly rhetorical question, but it's
no longer me who's the default fallback for the dirt work <g>
CU
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Jan 9, 2009 4:08 AM
in response to: kschaefe
|
|
|
That is a good idea.
Tibi
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 18, 2009 5:45 AM
in response to: tiberiu
|
|
|
More opinions, please? Still want to go final now without intermediate milestone or at least without code breaking changes before final - but seem to be the minority <g>
Cheers
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 18, 2009 7:21 AM
in response to: kschaefe
|
|
|
Here are a list of bugs that are (or could be) API-breaking:
903: Rename abstract classes to prefix Abstract
963: Evaluate and solve generic warnings (an umbrella bug for other issues)
972: FormatStringValue should return EMPTY for unhandled values
986: Fix improperly generic Painters
987: AbstractPainter subclasses improperly expose methods
990: Remove getXXXAction from JXImageView
991: JXImageView actions should extend UIAction
1008: Create JXStatusBar.Separator and UI delegate
1016: JXDialog should use JXRootPane by default
1018: Ensure all super constructors exposed (if appropriate)
1030: CompoundPainter.transform should be painter effect
1031: AffineTransform factory methods should be Painter effects
1034: RepaintManagerX does not allow to use other RepaintManagers
I am not making a claim to timeframe or feasibility of any of the aforementioned bugs, but I did want to capture a list of the bugs.
Karl
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 20, 2009 3:54 AM
in response to: kschaefe
|
|
|
Another one, just for completeness of the list (though it's indirectly covered by 963):
1042: CellContext should not be generic (as Karl convinced me
Cheers
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 20, 2009 5:14 PM
in response to: kschaefe
|
|
|
My preference would be to go straight to 1.0
If there is a 0.9.6 I would ignore it and wait for 1.0 anyway
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 27, 2009 6:57 AM
in response to: rturnbull
|
|
|
I would support breaking api in 0.9.6 cause it will probably expose some bugs that can be fixed in 1.0.
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Feb 27, 2009 6:20 PM
in response to: markokocic
|
|
|
> I would support breaking api in 0.9.6 cause it will
> probably expose some bugs that can be fixed in 1.0.
Good idea.
I change my vote.
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 2, 2009 11:57 AM
in response to: rturnbull
|
|
|
I'm sure you get this all the time, but is there any ETA on 1.0 release? We're still using 0.8 from late 2005, but I don't want to upgrade until 1.0 if I can help it.
Thanks
Erik
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 2, 2009 10:06 PM
in response to: evickroy
|
|
|
> I'm sure you get this all the time, but is there any
> ETA on 1.0 release?
We tried to aim for end of Q1, but seeing the amount of open issues for 1.0 I don't think this is realistic anymore.
> We're still using 0.8 from late
> 2005, but I don't want to upgrade until 1.0 if I can
> help it.
If you didn't need to upgrade since then, few months here or there and intermediate release is probably not a problem for you. Care to explain why you don't want to upgrade to anything less then 1.0?
Jan
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 5:09 AM
in response to: rah003
|
|
|
Given the sentiments, here, it seems that an 0.9.6 is in. Can we set a date for finishing the breaking changes to get an 0.9.6 out?
Karl
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 5:37 AM
in response to: kschaefe
|
|
|
> Given the sentiments, here, it seems that an 0.9.6 is
> in.
Indeed - seems like I'm the squashed minority <g>
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 7:05 AM
in response to: rah003
|
|
|
> > We're still using 0.8 from late
> > 2005, but I don't want to upgrade until 1.0 if I
> can
> > help it.
>
> If you didn't need to upgrade since then, few months
> here or there and intermediate release is probably
> not a problem for you. Care to explain why you don't
> want to upgrade to anything less then 1.0?
>
> Jan
Life being what it is, we can't get any time alloted for making code changes to existing production code that's seen as unneccessay. It's always rush, rush, rush to bigger and better things these days. We made heavy use of the autocomplete functionality, so I know that we'll have to make some code changes for it, but I'm not sure what else or to what extend. I managed to squeak a couple of days from our current project plan that we might be able to use to upgrade some libraries, but I'd prefer to upgrade to a 1.0 release if possible since generally speaking the API is more stable and less prone to change. I know that SwingX is rather mature and stable for a pre-1.0 release, so I'm not against migrating to 0.9.6, but it may be another 4 years before we're able to upgrade again provided any of us are still around.
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 9:03 AM
in response to: evickroy
|
|
|
> Can we set a date for finishing the breaking changes to get an 0.9.6 out?
Yes we can.
Let's see ... since I guess I'll be the one making it, what works best for me is either this weekend (March 8th) or the next weekend (March 15th).
BTW, the disk space issues are said to be resolved (the offending VM have been removed from the zone), so hudson should be working fine.
@erik: Thanks for explanation. I'm glad it is not anything else then that.
Cheers,
Jan
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 9:23 AM
in response to: rah003
|
|
|
I'm for the 15th so we have a little time to fix the issues that we want to fix (the API breaks).
Karl
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 3, 2009 10:04 AM
in response to: kschaefe
|
|
|
okay, the 15th increases the probability that I can contribute to this - but not much. A couple of suggestions as to procedure:
- first do any non-breaking changes
- tag the code-base (being paranoid, but better one tag too many than one too less)
- then do the breaking stuff (and don't forget to document it on the SwingX change history wiki page)
additionally, I would love to see the auto-generated beans testing removed (or with the same effect: renamed to something that's not included into the build). It's just grossly embarassing to have all that noisy logs of success as well as not-yet-done (and most probably never possibly done). BTW, the build is failing since the last change to the painter method visibility - Hudson is running, right? To repeat the obvious: it's the responsibility of the committer to make sure the build isn't broken after a commit (pointing fingers, lalalalala ... hopefully not backfiring any time soon <g>)
Have fun!
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 4, 2009 10:47 AM
in response to: kleopatra
|
|
|
> okay, the 15th increases the probability that I can
> contribute to this - but not much. A couple of
> suggestions as to procedure:
Fine 15th it is then.
> (and most probably never possibly done). BTW, the
> build is failing since the last change to the painter
> method visibility - Hudson is running, right? To
> repeat the obvious: it's the responsibility of the
> committer to make sure the build isn't broken after a
> commit (pointing fingers, lalalalala ... hopefully
> not backfiring any time soon <g>)
Keep pointing the fingers, but please also read the logs from failures.  The build failed first at 2am on March 1st, before visibility changes (in fact there were no code changes at all at that time, only the date change and fixed build scheduled for 2 am) and failing test is related to setting of JXMonthView ... Since it had similar issues in the past I suspect it has something to do with the date change. But I'll check it out and try to fix it, nonetheless.
Wanted to add link to the first failing build, but seems like someone is trying to bring the server down ... all i get is
"Maximum Connections Reached: 4096 -- Retry later" ... I can't imagine there are 4K people browsing our web at a same time ...
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 5, 2009 3:00 AM
in response to: rah003
|
|
|
>
> Keep pointing the fingers, but please also read the
> logs from failures. The build failed first at 2am
> on March 1st, before visibility changes (in fact
> there were no code changes at all at that time, only
> the date change and fixed build scheduled for 2 am)
> and failing test is related to setting of JXMonthView
> ... Since it had similar issues in the past I suspect
> it has something to do with the date change. But I'll
> check it out and try to fix it, nonetheless.
>
pleading guilty as accused I stopped reading at testAllPainterPCEFiring because
a) that comes from the auto-created test which I won't touch, that's completely your babe (and still want you to remove it from the automated build <g>)
b) assumed it was around the time you fixed the visibility of some painter methods
Now looking at it, it's yet another nice example of how auto-generated test data will always fail miserably because it relies on a general assumption which is wrong in the special case. The general assumption is
bean.setProperty(myProperty);
assertEquals(myProperty, bean.getProperty());
it fails in all contexts where bean somehow modifies the given property. That's exactly what happens in the JXMonthView's firstDisplayedDay: it's always the start of the month. So expecting something like the middle of the month was simply the wrong assumption.
> Wanted to add link to the first failing build, but
> seems like someone is trying to bring the server down
> ... all i get is
> "Maximum Connections Reached: 4096 -- Retry later"
> ... I can't imagine there are 4K people browsing our
> web at a same time ...
still the same - coooool, so much interest <g> Looks like yet another variant of crumbling infrastructure ...
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 9, 2009 2:54 AM
in response to: kleopatra
|
|
|
speaking of test assumptions: we again hit the DST toggle (our build server is located somewhere in US?) in one of the date interval testing methods. The build was so shocked, that it is hanging (since Friday or so) <g>
Not sure how - nor even if - we should handle those. Options:
- use a fixed date and time always
- always guard against interval boundaries being in the same DST realm
- do nothing, after all it's happening at most twice a year any given server
personally, I prefer to have a certain natural variance in test data - this way we did stumble across real problems already. And being lazy, I would tend to the last option.
Opinions?
Jeanette
BTW: any non-breaking issues in-the-work? If not, we could tag the code today or tomorrow and start working on the breaking issues.
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 9, 2009 9:52 AM
in response to: kleopatra
|
|
|
No, non-breaking issues from me.
Why do these things happen, just as my schedule tightens? I'll only have time for working on breaks.
Karl
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 9, 2009 11:52 AM
in response to: kleopatra
|
|
|
> speaking of test assumptions: we again hit the DST
> toggle (our build server is located somewhere in US?)
> in one of the date interval testing methods. The
> build was so shocked, that it is hanging (since
> Friday or so) <g>
are you sure this is the cause?
[SwingX Continuous Build] $ cvs -Q -d :pserver:guest@cvs.dev.java.net:/cvs co -P -d workspace -D "Monday, March 9, 2009 6:49:34 PM UTC" swingx
cvs [checkout aborted]: connect to cvs.dev.java.net(204.16.104.198):2401 failed: Connection refused
FATAL: CVS failed. exit code=1
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 9, 2009 4:11 PM
in response to: rah003
|
|
|
no, was joking - you probably missed the grin Probably different problems.
The broken build due to the test failure was build #1682 (05.03.2009 02:01:35), the failing test
org.jdesktop.swingx.calendar.DefaultDateSelectionModelTest.testSingleIntervalSelection
Schlägt fehl seit 1 Build (Seit Instabil#1682 )
Dauerte 7 ms.
Error Message
null
Stacktrace
junit.framework.AssertionFailedError: null
at org.jdesktop.swingx.calendar.DefaultDateSelectionModelTest.testSingleIntervalSelection(DefaultDateSelectionModelTest.java:403)
(an aside: those are some legacy tests, someone loving to call assertTrue(somthing.equals(somethingElse) - thus giving us the pleasure of the guess game of what was expected as to what exactly was different)
After cleaning that code to use assertEquals, fix the date to the build time and running with the US/Eastern timezone, I got the failure as well. Reason is that the start of the tested interval was before the second sunday of march and the end after. That particular selection model keeps the time part ... soooo ... blowing.
The built after that first failure was the one running forever (with the error message you cited? didn't check). Not sure what's going on (had problems to connect to cvs during the day, but could be my occasionlly shaky mobile connection)
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 16, 2009 1:02 AM
in response to: kleopatra
|
|
|
> no, was joking - you probably missed the grin Probably different problems.
yeah, must be ... it was hanging cvs connection again.
BTW, are we done with all the changes and ready for the 0.9.6 release or is anything still open?
Latest changes definitively broke the demos build if anybody noticed ...
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 16, 2009 3:16 AM
in response to: rah003
|
|
|
Jan,
>
> BTW, are we done with all the changes and ready for
> the 0.9.6 release or is anything still open?
>
nothing from here (just took the oportunity to squeeze in the internal use of Highlighters in MonthView, if they blow better now than after final
BTW, there's a maybe p1 maybe regression (or maybe neither, just reopened because the failing test is commented with the issue number #854) in errorpane
> Latest changes definitively broke the demos build if
> anybody noticed ...
doohhh ... fixed some, but that PainterDemo is still broken: is there any way to remove the now incorrect generic parameter automatically? Seem to remember that Eclipse had a "search similar errors" and quickfix all in one go - but can't find it right now.
CU
Jeanette
forgot: build is hanging again 
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 19, 2009 8:07 AM
in response to: kleopatra
|
|
|
> Jan,
> > BTW, are we done with all the changes and ready for
> > the 0.9.6 release or is anything still open?
>
> nothing from here (just took the oportunity to
Thanks. Karl, are you done as well?
> BTW, there's a maybe p1 maybe regression (or maybe
> neither, just reopened because the failing test is
> commented with the issue number #854) in errorpane
I'll try to fix it before release.
> forgot: build is hanging again
I've noticed. Restarted hudson, but it didn't seem to help. I'll ask Alex to bounce the glassfish.
|
|
|
|
|
|
|
|
|
Re: Making 0.9.6 an API-breaking release
Posted:
Mar 19, 2009 8:35 AM
in response to: rah003
|
|
|
Jan,
> Thanks. Karl, are you done as well?
Yeah, I am.
Karl
|
|
|
|
|
java.net RSS
