FEST Assertions 2.0M9, FEST Reflect 1.4.1 and FEST Util 1.2.4 release

69 views
Skip to first unread message

Joel Costigliola

unread,
Feb 25, 2013, 6:14:45 AM2/25/13
to easyt...@googlegroups.com
Hey guys,

I have released FEST Assertions 2.0M9, FEST Reflect 1.4.1 and FEST Util 1.2.4 to fix an incompatibility introduced in 2.0M8.
I have used them in fest-examples (compatibility branch) project without problems, so I hope it will ok for everybody.

Moreover fest-assert-core 2.0M9 comes with two other small bugfixes :
  • #131 - ObjectArrayAssert.containsExactly() works wrong
  • #138 - containsExactly() throws ArrayIndexOutOfBoundsException
Have a nice day !

Joel

Mark Derricutt

unread,
Feb 27, 2013, 10:53:26 PM2/27/13
to easyt...@googlegroups.com
Joel Costigliola wrote:

Hey guys,

I have released FEST Assertions 2.0M9, FEST Reflect 1.4.1 and FEST
Util 1.2.4 to fix an incompatibility introduced in 2.0M8.


W00t - time to give them a spin.

I guess we can resolve http://jira.codehaus.org/browse/FEST-451 now.

Is github the new official bug tracker or is the codehaus jira still golden?

Alex Ruiz

unread,
Feb 28, 2013, 1:35:00 AM2/28/13
to easytesting
Mark,

I've been working on new versions of fest-swing, fest-assert (1.x) and fest-reflect that use the same dependencies. I was hoping to release them in February. It is taking longer than usual since the code in fest-swing is really old and it does not use Ansgar's self-types. As part of the updates I'm rewriting the parts that can use self-types.

Another unexpected event is that I'm busier than ever at work, which has delayed the release as well. I'm aiming at mid-March.

Cheers,
-Alex


--
You received this message because you are subscribed to the Google Groups "easytesting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to easytesting...@googlegroups.com.
To post to this group, send email to easyt...@googlegroups.com.
Visit this group at http://groups.google.com/group/easytesting?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Ted M. Young [@jitterted]

unread,
Mar 11, 2013, 12:49:04 PM3/11/13
to easytesting
Hi Alex,

Two questions:

1. How likely is a mid-March release for the "new" 2.0?
2. Will the "new" 2.0 be binary and/or source-compatible with the existing 2.0M10 "release".

A search (admittedly a quick one) didn't surface anything regarding #2, so I just want to make sure that if my team starts using the FEST-Assert 2.0M10 release that we won't have major hiccups in taking on the major rewrite that you're working on.

Thanks,
;ted

Alex Ruiz

unread,
Mar 11, 2013, 3:55:23 PM3/11/13
to easytesting
Hey Ted,

1. It is not going to happen in March, unfortunately. I currently don't have any spare time :(
2. The new 2.0 will not be compatible with any current milestone. I have trimmed *a lot* of "fat" from it.

The size of 2.0 library will be really, really small. We'll ship even less assertions than the 1.x (e.g. no IterableAssert or ThrowableAssert, no more direct access to properties, etc.) There are things that are just redundant, unnecessary, too hard to maintain or just plain wrong, and need to be removed. Cleaning it up turned out to be a huge task.

The key is to make the library extensible. One way is through APIs and the other one is Joel's Eclipse plug-in.

Cheers,
-Alex


Ted M. Young [@jitterted]

unread,
Mar 11, 2013, 4:04:21 PM3/11/13
to easytesting
Thanks for the info, Alex, that'll help guide my team. I wonder if it makes sense to talk about your 2.0 library as version 3.0? I'm sure I'm not the only one who would be confused/unhappy with your refactored 2.0 release being incompatible with existing milestones. (And releases with the version number of 3.0 are always the _best_!)

;ted

Alex Ruiz

unread,
Mar 11, 2013, 4:40:31 PM3/11/13
to easytesting
Well, 2.0 final has not been released and all the milestones are subject to change. They should be used "at your own risk". As long as there is no 2.0 final, any changes between milestones is fair game. Luckily we did not have any "RC" release :)

I hear you, Ted. I thought about having a 3.0 release with my changes. The thing is that releasing any 2.0 Mn as 2.0 final would be really, really bad. Like I said many times, the architecture is poor, the code base has too much duplication and bloat and even the code itself does not have a consistent style. It would be a crappy final release. I'd rather have a small number of users feel the "upgrade" pain than later one make a bigger number of users feel that pain when going from 2.0 to 3.0.

Cheers,
-Alex


Joel Costigliola

unread,
Mar 11, 2013, 8:04:09 PM3/11/13
to easyt...@googlegroups.com
Hey, I feel 2.0Mx API is not that bad ! Ok, some internals parts are not so clean but I don't think users really care about Fest internals, they care about having a rich and simple API.

I know a lot of people using 2.0Mx and for me a 3.0 would definitely make sense, users will be free to use either 3.0 or 2.0 if they don't want to make a painful migration.
Alex, releasing a 2.0 and move on working on 3.0 would also be a good choice because you will have all the time you need to work on it.

BTW, I don't understand why IterableAssert or ThrowableAssert are so bad they are not in the refactoring going on ...
As a user, I just want rich strongly typed assertions, Iterable and Throwable included (and even more).

Will we provide a fest "extended core" lib/plugin with IterableAssert or ThrowableAssert ?
I'm not against having a small core if we provide an extended lib with the most of assertions available in 2.0Mx

My 2 cents,

Joel


Mark Derricutt

unread,
Mar 11, 2013, 11:58:06 PM3/11/13
to easyt...@googlegroups.com
Alex Ruiz wrote:
> 2. The new 2.0 will not be compatible with any current milestone. I
> have trimmed *a lot* of "fat" from it.
>
> The size of 2.0 library will be really, really small. We'll ship even
> less assertions than the 1.x (e.g. no IterableAssert or
> ThrowableAssert, no more direct access to properties, etc.) There are
> things that are just redundant, unnecessary, too hard to maintain or
> just plain wrong, and need to be removed. Cleaning it up turned out to
> be a huge task.
Er, if you're trimming A LOT of the fat, I daresay a Milestone release
with that fat trimmed would be nice. Esp. for us early adopters who've
already caught a fair few esoteric breakages along the way....

Mark

Alex Ruiz

unread,
Mar 12, 2013, 1:23:35 AM3/12/13
to easytesting
No worries, Mark, there will be a good number of releases after I finish this refactoring, in case of bugs or stuff that I should not have removed.

This was my original plan:

1. End of February/Early March: release FEST-Swing 2.0, FEST-Assert 1.5 and FEST-Reflect 2.0
2. Mid-March: FEST-Assert 2.0 RC1

But too many unexpected things had happened and I really don't have too much of spare time now. Everything is delayed at least for 2 months. Now I'm aiming at a mid-June release.

Cheers,
-Alex


--
You received this message because you are subscribed to the Google Groups "easytesting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to easytesting+unsubscribe@googlegroups.com.

Mark Derricutt

unread,
Mar 12, 2013, 7:05:38 AM3/12/13
to easyt...@googlegroups.com
Understandable - work, life, family - they ALL come first, unless I have
a bug - then you best be on your toes ;p

Always appreciated the work you've put into FEST in the past ( and future ).
Reply all
Reply to author
Forward
0 new messages