A huge disadvantage of Swiz : version number, road map? Cairngorm 3 ?

[Jason C]

Dear all in the Swiz community,

I am a senior Java developer and have been working with Struts and
Spring Framework for years. As a developer getting into the Flex
development, I have been researching for the best framework for the
Flex development for our needs because we all know that's a must to
ensure a success of a project.

Our corporate project standard is right now, no surprise, Cairngorm. I
know Swiz can do everything Cairngorm can do in a much cleaner way
because I did a clean conversion by myself following one of the
samples on the blog and I know it's fairly simple and it makes our
codes much easier to read and work on.

There is no clear road map from the Swiz and we don't really know why
it's still in it's 0.6.4 release. Showing on the site (http://
swizframework.org) is not very clear about this, either. In my
opinion, I think that's a huge "defect" to me. Either the team thinks
that it's not ready for real enterprise corporation IT to really
embrace it or there is still huge piece(s) missing before the Swiz
team wants to make it to the final 1.0 release. How could I convince
my manager that's Swiz has all the features we need (we are not using
modules for our current projects yet) even though it's still in the
version 0.6.4. Marketing-wise, I just don't see that 0.6.x number does
really make any sense to me.

That's way it's very difficult for me to recommend Swiz to my manager
for new projects since most of the developers in our group do have the
knowledge of Cairngorm and it's kind of a "proven" framework in it's
2.x release already.

I just realized today that the official module support from Cairngorm
is coming in release 3 (still in beta)

http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm+Libraries

And if you take a closer look, it's an extension of PARSLEY
framework !! How original they are !! (see their disclaimer here)
====================================================================================
Module Library 0.1 - Parsley Extension - beta

The Cairngorm Module library is an extension to the Parsley
Application Framework designed to simplify the configuration, loading
and displaying of modular content. It contains infrastructure class,
view components and a mechanism for loading modular content on demand
in response to Parsley messages. The library is in beta and expected
to change before release 1.0.

======================================================================================

Why shouldn't people just pick Parsley ( http://www.spicefactory.org/parsley)
framework directly and by pass the Cairngorm when they see this is
beyond my comprehension.

So, please please please do produce a clear road map for the Swiz if
you do not think it's time to get Swiz into the main stream based on
any concern you may have. Otherwise please do make it jump to 1.0.0
much faster than it's current pace.

Thanks and best regards,

Jason

[Jason Crist]

Interestingly, I am Also a Jason C who has been doing a lot of research on frameworks for our large enterprise applications.  I've picked Swiz over the other options, but I have to agree that the version (and lack of a clear roadmap) has raised a few eyebrows from my higherups.  Fortunately they trust my decision but a Swiz 1.0 (or at least a road map that shows we're not waiting for anything that will be coming in 1.0) sure would go a long way to making everyone happy.

Jason Crist

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=en.

[Cliff Meyers]

I agree. Although it's silly to judge a framework based on its
version number, it does create a certain perception that some people
place value on. I think the lack of a roadmap is a more legitimate
concern that does need to be addressed.

-Cliff

[Ben Clinkinbeard]

You will both be happy to know a 1.0 pre-alpha should be released this
week. We had talked about publishing a roadmap at some point, but
ended up deciding to start with a fresh codebase and targeting a 1.0
release. I can't say exactly when the 1.0 final will be ready but I am
hoping it will be in the next couple of months.

As for the case of version numbers in general, I don't buy into the
idea that they mean anything. If we had decided to call each release a
whole new version we'd be at version 8 or so, so its obviously a
meaningless number. That being said, I know the suits are often
interested in meaningless numbers, so our impending 1.0 will hopefully
satisfy everyone.

Ben

On Dec 9, 4:01 pm, Jason Crist <jcr...@pbking.com> wrote:
> Interestingly, I am Also a Jason C who has been doing a lot of research on
> frameworks for our large enterprise applications.  I've picked Swiz over the
> other options, but I have to agree that the version (and lack of a clear
> roadmap) has raised a few eyebrows from my higherups.  Fortunately they
> trust my decision but a Swiz 1.0 (or at least a road map that shows we're
> not waiting for anything that will be coming in 1.0) sure would go a long
> way to making everyone happy.
>
> Jason Crist
>

> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[Borek]

Hi Ben,

no offense how can a pre-alpha satisfy anyone? (I assume that "pre-
alpha" means that hardly anything really works, otherwise you would
call it at least alpha.)

Why not rename 0.6.4 to 1.0 to get rid of the concerns (which are
valid IMO) and call the complete rewrite a version 2? Because it is,
honestly.

Regards,
Borek


On Dec 9, 10:29 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:

[maxim.porges]

Ignore the version number. We're using Swiz in an app slated for
production next year; it's mature and it works fine. If your boss
can't understand that, have him post questions on the forum. If he's
still not satisfied, it might be time to find a new boss. :)

- max

> Why shouldn't people just pick Parsley (http://www.spicefactory.org/parsley)

[Ben Clinkinbeard]

> no offense how can a pre-alpha satisfy anyone?

I didn't and wouldn't say that it would "satisfy" anyone. I just
figured that knowing a 1.0 release is around the corner would be
considered good news. If you disagree, then you are entitled to your
opinion.

> (I assume that "pre-alpha" means that hardly anything really works, otherwise you would

> call it at least alpha.)

Here we are back to arbitrary terminology. In fact, autowiring and
mediation, and a new mechanism for custom metadata processing are in
place, allowing users to get a good sense of what the framework will
be capable of. Things like SwizConfig, executeServiceCall() and
CommandChain are not yet implemented. The API may still fluctuate a
bit before a final release. Like version numbers, it doesn't really
matter if our release plan goes pre-alpha, alpha, beta, final or 1.0
RC1 through 1.0 RC25 does it? They are just names and numbers, and
will always mean something different to different people. I actually
know of an instance where the current code has begun to be integrated
into a large enterprise app, so the functionality is obviously not too
sorely lacking.

> Why not rename 0.6.4 to 1.0 to get rid of the concerns (which are
> valid IMO) and call the complete rewrite a version 2? Because it is,
> honestly.

Because we don't feel like that is beneficial or reasonable. Have you
ever seen a piece of software increment their version number without
adding anything? I would call BS if a project did that, so we're not
going to.

As much as I would like 1.0 to be ready right now, it's not. Not to
sound like a jerk, but it will be ready when it's ready. We're not
going to play games with the version numbers in the interim.


Ben

[Borek]

Hi Ben,

what seems like a preference issue to you (you, personally, don't
think version numbers are important) is a decisive factor for some of
us. We need v1.0 for our bosses, simple as that. What you have now is
some alpha that will be in development for months. I'm sorry to say
that but Swiz 0.6.4 or Swiz 1.0 alpha is about as good as no Swiz from
my boss's point of view. And that's a big shame.

Please reconsider the versioning issue. If you rename 0.6.4 to 1.0 and
provide an explanation no one will blame you. Java has been renamed
from 1.5 to 5, several .NET technologies jumped from v1 to v4, it's
nothing uncommon in software development world if it's for a good
reason. And what reason can be better than having more Swiz developers
out there :)

Regards,
Borek

[Sönke Rohde]

Just to add my two cents: Swiz 0.6.4 is absolute stable, robust and
proven.
I think at the end the outcome is important and not the version number.
I can say that I have successfully shipped software made with Swiz
0.6.2 and 0.6.4 to a very large audience (> 1Mio).
Swiz has had many releases and the fact that we are conservative with
version numbering is simply our choice. The fact the Java changed from
1.5 to 5 is a good example that a version number does not mean anything.

Sönke

> --
>
> You received this message because you are subscribed to the Google
> Groups "Swiz Framework" group.
> To post to this group, send email to swiz-fr...@googlegroups.com.
> To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com

[Borek]

Hi Sönke,

you may be missing my point. I am not questioning that you can build
stable and successful software with Swiz for an audience of 1Mio but
I, personally, can't use Swiz even for small internal project for 20
people if the version _number_ is not at least 1.0 (my boss won't be
happy to use 1.0 either but at least he will consider it; it is an
absolute no-no for something with a version tag of 0.6.x).

You say that the "version number does not mean anything" when it
actually makes a world of difference to many of us.

Regards,
Borek

[Sönke Rohde]

Don't get me wrong but the problem is not the version number but
likely your boss.

>>> fram...@googlegroups.com.

[ben senior]

Umm... the fact that Java changed its version number from 1.5 to 5
means they probably saw the marketing advantage in doing so, even if
the change didn't matter technically speaking. I think that's what
the guy's trying to say.

[Jason Crist]

I absolutely agree with Borek.  I love using Swiz.  It passes all of my tests and works in every way I need it to.  But using it is a "secret" because of the version number.  The perception given by the version IS important in my company.  It's great that a lot of people will choose to use Swiz based purely on the stability on the code.  But I can tell you my boss is NOT going to spend time in the forums, on mailing lists, or discussing the stability of Swiz.  He SHOULDN'T be spending his time doing these kinds of things; he's already got a lot on his plate making sure that our projects run smoothly.

Jason Crist

[Jason Crist]

Oh my goodness.  Don't say the problem is my boss.  My boss is a fantastic guy to work for.  My company is a great place to work.  Especially since there is no "measuring stick" for the version (i.e. a roadmap) he has two things to base his decision of using a library; the version number (which should imply stability) and my opinion.  I'm fortunate that my opinion carries a lot of weight, but I'm sure that there are other bosses that are also good that just can't sell a <1.0 library to THEIR bosses.  That's the way it works and "up and leaving over a versioning disagreement" is just a silly reason to change bosses.

Boy I'm getting fired up.  But it's not my decision.  I'm not an author; I'm not even a contributer (though I wish I had time to be).  But to say that "version doesn't matter" is like saying "size doesn't matter".  It matters to some and you can't argue that it doesn't.

Jason Crist

[Jason C]

Dear all Swiz developers,

I am so glad that my post introduce such a healthy discussion inside
of Swiz Community.

I can't agree more about the stability of this framework and that's
exactly the reason that we should promote it to where it should be.

As for my boss, he is a very technical-hands-on guy himself and he
knows exactly how bad the Cairngorm is.
However, since that was "officially" introduced to us by the so-
called "Adobe Consultant Service" and it is a "industry-proven" and
"industry-leading" framework to be used, without an official release 1
of Swiz just make it almost impossible for us to really make the
switch or even use it for a new project. And we all know that
Cairngorm is going to be Release "3" really soon !?

I don't want to explain to my boss' boss' boss about using a framework
that's not even "ready" but it is really "ready for the prime time",
blah blah blah.
They will just tell us that we shall not defy the recommendation from
the Flex "experts" in Adobe.

I believe there are a lot of people working for huge enterprise-level
applications or companies are having the same concern so they can't
use it.
Then who are the losers? The entire Swiz community!! We miss the
chance to have this framework introduced into big corporations again
and again!!
It's all due to the version number? It's such a shame.

And no, I am not planning to change my boss now since I need to $ to
feed a family of 4. As I did search through the Dice.com the other
day,
there are not that many adopters of Flex in this tough environment
yet. I am only hoping this "brutally simple" Flex framework Swiz 1.0
can make
the difference and make the Flex even more popular than before. And
then I can bring it to my next job. That's exactly what I did for the
Strus and Spring
frameworks.

This reminds me about my Struts and Spring frameworks experience. I
used the Struts since 0.9 and the Spring since it's 1.x. When they
were
still not that popular at that time, I knew their potential and
adopted them into my daily jobs and it proofs that I was right (now I
am using Spring MVC, by the way).
Let 's cross our fingers and hope that Swiz 1.0 will do the same.

Best Regards,

Jason

[Brian Russo]

We're using swiz and don't care about the version number nonsense.
I've always thought it dumb as well.

> --
>
> You received this message because you are subscribed to the Google Groups
> "Swiz Framework" group.
> To post to this group, send email to swiz-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> swiz-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/swiz-framework?hl=en.
>
>
>

--
Sent from my mobile device

[Brian Kotek]

While I also agree that the version number doesn't actually mean anything, I can see how from a "management" perspective it raises an eyebrow. That said, as Ben mentioned, a 1.0 release is on the way, and hopefully that will help resolve the issue for people who are running into this problem. So while the solution won't be immediate, it is coming.

[Rafael Nami]

Don't know about you guys, and not personally offending any of you, but stability means "if it works right". I have both Swiz and Cairngorm projects deployed in production. I've used Swiz since 0.3 version IN PRODUCTION without any flaw (it means from last year), and we even didn't had mediateBubbling yet. And I can tell you FOR SURE that cairngorm gives you much more pain in development AND code bugs than swiz, that has a much cleaner way of coding.
If you guys don't think that this is a good argument, try to do a quick proof of concept. You'll end up with the same opinion that I had (that cairngorm, even using it right, suck, and Swiz rox:) )

Kind regards, and Best All

2009/12/10 Brian Kotek <bria...@gmail.com>

[Cliff Meyers]

I think just about everyone on this DL agrees that Swiz is solid no
matter what version number is applied to it. The problem is that
people in management who make important decisions don't understand
these things. Having a more "legit" version number would help satisfy
those people, even if they are morons for comparing frameworks based
solely on their version number.

I know we're all looking forward to the 1.0 release now. :)

-Cliff

[Ben Clinkinbeard]

OK, some bosses care about version number, point taken. That being
said, I don't believe changing our version number is the right thing
to do. You started using Swiz as a < 1.0 release, so I don't feel like
it is fair to expect it jump to that at some artificially chosen point
in time. We are working on 1.0, and want to get it released as badly
as you want it released.

Hang in there, I don't think you will be disappointed with what we
produce.

Thanks,
Ben

[Brian Russo]

I just have to jump in again and add that I think this conversation is
pretty hilarious; this is a manager education problem + stupidity of
people; I don't think Ben should bump it to satisfy the clueless; that
said it doesn't matter and we'll be using swiz in our enterprise apps
based on it being solid; not its version - whatever he wants to do on
this issue is fine w/me as it is irrelevant.

[Dynamic_Internet_Development]

I have to agree with Brian on this one. This thread has been a
humorous one to read.

Our team has been using Swiz since around version .4 in a Enterprise
Level Production Environment. The quality of the code, the consistent
advancements, and the high quality & availability of support are what
makes Swiz a great choice, not it's version #. I also can't agree more
with Ben's statement that " You started using Swiz as a < 1.0 release,

so I don't feel like it is fair to expect it jump to that at some
artificially chosen point in time. "

Not to offend anyone who feels otherwise but consider these 2
examples:

1. If I create a new framework tonight, and name it v 1.0 and then
release an update everyday for three days incrementing my version # by
one every time does that mean in 4 days my framework (which would be
at v 4.0) dwarfs Swiz AND is better than the upcoming Cairngorm 3
release?

2. Isn't comparing the "competency" of a framework on version # the
same as comparing the "competency" of a programmer based solely on the
# of lines of code he can write in a given day?

Consider me a happy Swiz developer no matter the version (we can even
start going backwards), just keep the awesome features going. Great
Job Swiz Team!

On Dec 10, 3:04 pm, Brian Russo <br...@beruna.org> wrote:
> I just have to jump in again and add that I think this conversation is
> pretty hilarious; this is a manager education problem + stupidity of
> people; I don't think Ben should bump it to satisfy the clueless; that
> said it doesn't matter and we'll be using swiz in our enterprise apps
> based on it being solid; not its version - whatever he wants to do on
> this issue is fine w/me as it is irrelevant.
>

[Borek]

It's interesting to see that the Swiz devs should rather lose some of
their potential users than do a simple change to the version number
but we'll have to accept it. I'm sure Swiz 1.0 will be a great release
and I will be following its development closely. However, in the
meantime, I will have to chose a framework whose team is more
practical about the non-technical issues.

Thanks,
Borek

[DannyT]

Seeing as said bosses aren't necessarily involved in reading up on this list etc and seeing how swiz is open source. Couldn't you just fork the project call it 'Swoz', stick a one page wordpress site up or something and slap a big 1.0 sticker on it.

*note this is somewhat tongue in cheek but does highlight the vagueness of version numbers, I do however sympathise with those who's bosses are (somewhat) understandably concerned by pre-1.0 products

Would publishing a version number "rationale" help along the lines of:

0 . 6 . 3
ma.mi.p

ma - major - all planned features are complete and production worthy
mi - minor - all implemented features are production worthy but more features will be added
p - bugfixes and other updates

with the possible addition of:
d - development - non production ready version for publich feedback (e.g. alpha, beta, RC etc - 1.0.0a)

People could then use that to demonstrate to bosses that there is no risk in using Swiz in it's current form as it is deemed production worthy already.

Just a fence-sitting suggestion to try and please all parties :)

2009/12/11 Borek <bor...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=en.

--
http://danny-t.co.uk

[Borek]

Forking is also something I considered and I would probably do it if
Swiz was the only lightweight framework out there and there was really
no other way to convince my boss but actually, this will be an
opportunity for me to explore the framework space a little more (and,
quite honestly, the team's response to this issue makes me want to
explore a little bit more). BTW, I will still be using Swiz for my
projects where no politics is involved - it is a nice piece of
technology.

Regards,
Borek

> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[Sönke Rohde]

If you refer to my reply I did not want to hurt your feelings and if
so I apologize.
I only wanted to make clear, that a version number should not be the
final criteria for your boss to decide which framework to use and if
so, in my personal opinion he makes a mistake.
Sönke

>>> fram...@googlegroups.com.

[Jason C]

As of my first post, please be aware of the other keyword "road map".
As for the countless open source
programs I had been researching on, there is no doubt that with a
clear "road map" showing on the home page
will also help in the decision making process.

As one of the core architects in my group, I do a lot of trial and
asserting the frameworks to be used within
our group. Usually, when I see a clear feature list (the list showing
on Swiz site is very good) and a road map,
that makes a very good case for the framework. But when I see the
version is still like v. 0.1, I will tend to think
that I will come back in three months even if the road map seems to be
interesting... That tells you the story about
how other new comers may be doing as well. (I am glad that I didn't do
that for the Swiz...)

We are living in a real world. Unless you are the boss yourself or
your boss agrees on whatever you said
without a question asked, a real-life business decision will be made
on all the factors we had talked about in this thread.

With a solid framework and dedicated developers working on this
framework, no one wants to see a split due
to the "non-technical" reason.

We should work as a more harmonic group of people to make this the
best framework in the world. Sarcastic
comments sometimes are funny, sometimes do hurt the entire group to
move forward.

Best Regards,

Jason C

[Brian Russo]

Part of our job is to explain things like this to non-technical people. If you cannot explain these issues to your management adequately then I'm sorry but you're not doing your job. Version numbers don't mean anything. Linux kernel has been on 2.6 for 2004. I guess that means they haven't improved it in 5 years? Better get those numbers up people!

Also passive-aggressive comments like:

"It's interesting to see that the Swiz devs should rather lose some of their potential users than do a simple change to the version number but we'll have to accept it."

.. don't help anyone either.

 - bri

[Ben Clinkinbeard]

While you may be disappointed with our response, I still can't
understand why you seem to be surprised by it. When you started with
Swiz did you really think "I know my boss won't go for it but I'm sure
they'll change the version number if I ask"? I'm not trying to be a
dick, but your insinuation that we are being ridiculous by not making
a fundamental change to our project because *three* people asked for
it is really aggravating.

My involvement in the project is not driven by how many users can we
get, it's to create the best piece of software I/we can.

Ben

> > > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsubscribe@go oglegroups.com>

[Paul Andrews]

Brian Russo wrote:
> Part of our job is to explain things like this to non-technical
> people. If you cannot explain these issues to your management
> adequately then I'm sorry but you're not doing your job. Version
> numbers don't mean anything. Linux kernel has been on 2.6 for 2004. I
> guess that means they haven't improved it in 5 years? Better get those
> numbers up people!

I think many people - particularly in a corporate environment will be
wary about ANYTHING with a release status pre 1.0. I have worked with
people who feel that investing in software before it's second full
release is unwise.

In many ways they are right - if a product hasn't yet reached an
official first release status, it may well be stable but the developers
haven't yet the confidence that it is a product that is mature enough or
feature complete to warrant release status. It also indicates that the
software is likely to have a smaller following. Open software grows and
dies according to the prevailing wind.

This isn't intended as a criticism of the developers or swiz - software
should be released when ready, not when people would like it to be
ready. I do understand the reluctance for companies to invest (time
and/or money) in products that are not mature in the market. It doesn't
mean the rest of us can't though.

[Jason C]

Every one here should just provide a peaceful statement for the
discussion going forward.

We are merely providing the experience regarding this issue based on
our background or the place
that we are working in. Some suggestion is to provide a different
strategy and mindset so the core
swiz team can take advantage about others' thought. It's not a voting
and it should not be see as some
one is against the others.

A best software (or open source framework) needs best developers to
provide the best technical design
and implementation. In addition, more people to contribute idea to
promote it and make it better accepted
to a even bigger group of people no matter how easy is their boss to
be convinced should make it got
adopted much faster. Isn't that all of us want?

Best Regards,

Jason C

[Borek]

Hi Ben,

I respect your standpoint and decision, just wanted to add a couple of
comments to maybe clear some things up.

* When I started with Swiz it was for a project where I had complete
control over all the tools and frameworks used. No I didn't have any
assumptions back then.

* I'm asking for the version number change because it is one of the
more viable options that are left. Some folks in this thread may find
it humorous that zero point something software would be disregarded
solely based on the version number but yes, world sometimes works like
that.

* While you describe the change as fundamental, I still don't really
understand what makes it so. Technically, there would be no change at
all and I don't see anything wrong about changing the version number
in the sake of getting more projects on board (therefore growing the
community which, although you may not be primarily driven by
(rightfully so), still should be an important thing for the Swiz
project as a whole). It would be interesting to know if the people who
generally don't care about the version number would mind jumping from
0.6 to 1.0 for non-technical but well documented reasons. BrianRu,
Rafael, Dynamic_Internet_Development?

This response is longer that it should have been already :) As I said
in the beginning, I accept your decision and don't expect the version
change any more. I just wanted to provide a little more background on
why is this issue such an important one to me and why I may be pushing
it a little bit more than I'm used to.

Regards,
Borek

On Dec 11, 2:54 pm, Ben Clinkinbeard <ben.clinkinbe...@gmail.com>
wrote:

[Borek]

Hi Sönke,

I was not referring to your reply specifically, no worries :) I agree
with you in all you write - yes, software should not be judged based
on the version numbers and yes, bosses make mistakes if they
disregards good software for arbitrary reasons. But it is unrealistic
to expect me or anyone else to change their job just because of that.

Thanks,
Borek

[Borek]

Hi Brian,

what you see as negative / aggressive is merely a statement of fact.
Some projects will not be able to use Swiz just because of the version
number, as ridiculous as you may find it.

Regards,
Borek

On Dec 11, 12:46 pm, Brian Russo <br...@beruna.org> wrote:
> Part of our job is to explain things like this to non-technical people. If
> you cannot explain these issues to your management adequately then I'm sorry
> but you're not doing your job. Version numbers don't mean anything. Linux
> kernel has been on 2.6 for 2004. I guess that means they haven't improved it
> in 5 years? Better get those numbers up people!
>
> Also passive-aggressive comments like:
>
> "It's interesting to see that the Swiz devs should rather lose some of their
> potential users than do a simple change to the version number but we'll have
> to accept it."
>
> .. don't help anyone either.
>
>  - bri
>

> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>
> > .

[Ben Clinkinbeard]

One point of clarification and then hopefully we can put this topic to
bed. The reason I see it as a fundamental change is because it would
disrupt our planning for the project's progression. Since we have 1.0
fairly close, changing 0.6.4 to 1.0 would mean 2.0 is released hot on
its heels. This would raise questions about why it took close to two
years to reach 1.0, and then 2 months to reach 2.0. In addition to
being something I simply don't believe in, it is something that would
have to be explained over and over again.

That is probably all I have to say on the topic, but keep an eye out
for the 1.0 alpha (decided to remove the pre based on your feedback)
which I hope to get out in the next few days. I had hoped to get it
out this week but real life got in the way.

Best,
Ben

[ag]

Hello all

This thread has gone a little bit out of proportion..but I still think
the idea behind the acceptance of swiz to enterprise software is
important.... In my opinion the two biggest problems of Swiz on the
field as far as bosses go are not the versioning/road map... its the
"References" and the "backer"...
1.Regarding the backer... swiz is not supported by a big company (like
cairngorm)..and this will not probably be changed...so nothing to talk
about that...
2.Regarding the references..... one of the first questions I am always
asked when I come to consult on a framework..Is, which big and small
companies are using it...for what projects... how big they are...how
big are the teams...etc..... I think that this aspect is a crucial
one.....and maybe, we as a team of architects/community can help swiz
by creating a repository/show case gallery/letters of references/ any
information from successful past projects with swiz...
(ofcourse...this has to comply with all the busines confidentialy
issues...etc) ....

A I see it , if I will be able to give a link to this reference to
some exec in a company ,and in it he will find people in a similar
state to his recommending swiz...for similar scale projects.... The
versioning won't mean a thing...

Welp...
These are my two cents....
Can't wait for v1. alpha
and thanks again to the swiz team for a remarkable framework

[maxim.porges]

Version numbers are irrelevant to the stability and usefulness of a
library. I think that's been established. If 0.6.4 was renamed to 1.0
and somebody's boss was suddenly happy about it being more stable or
legitimate without a line of code being changed, then I'm sorry, but
they are a fool. This isn't my opinion, it's a logical statement based
upon the fact that truy nothing else will have changed.

Get to the bottom of the issue with your boss: why is the label of the
version number important?

Let's says it's because they feel the API is mature/solidified. If so,
tell them that you can check out 0.6.4 and put it in your source
control system where it will never change. Whatever you build on it
will work the same forever. If you find bugs, you can fix them in your
copy since it's open source. As a matter of fact, we've done exactly
this since we have customized Swiz a little for our own needs and to
add some efficiencies. We develop software that we sell so it has to
be stable and high quality, and Swiz's version number has not
presented a barrier for us.

If it's because your boss feels 1.0 will be supported better, remind
him it's an open source project. It will be supported at the pleasure
of its contributors, or again, you can fix it yourselves. None of the
framework is rocket science. The likelihood of Swiz being commercially
supported one day seems slim. And if you look at the history of the
library, support has been pretty rapid in the form of bug fixes.

If it's any other reason, please post it here so that the educated
community can put his fears to bed. And if we can't do so, then I'll
say it again: find another boss. Anybody who would rather use an
inferior technical solution for no other reason than an arbitrary
label clearly lacks a rational thought process, and shouldn't be in
charge of people writing software. That statement is not meant to be
offensive; it's one borne of years of dealing with non-technical
managers making similarly team-crippling decisions for no other reason
than their irrational fear or lack of understanding.

- max

[Jason Crist]

Man, this has definitely gotten silly.  It sounds like it's those of us who think that version number implies something about a project versus those that don't.  And man, people are getting fired up about it too.  I admit I got a little carried away when it was suggested that I should quit my job because version numbers matter at my company, but man, people are STILL getting fired up.  Let's put this to bed already eh?  It's not going to change and we aren't going to change each other's opinions.  This thread will continue but we can only flame our opinions so many times before it gets old.  I'm happy to debate this 'till dawn over a few dozen beers, but let's leave it a philosophical discussion over alcohol.

The thing that all of us on the list have in common is that we like Swiz.  Let's concentrate on that.

Jason Crist

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Brian Kotek]

Agreed. The easy answer that I think everyone can understand is that the 1.0 release that is upcoming is introducing a number of fairly significant changes to the way things work, and part of the reason that the library is pre-1.0 is to allow for exactly this kind of change. I think people would be much more justifiably upset if Swiz were marked 1.0, and then 2.0 rolled around and wasn't backward compatible or broke some existing apps. Once we hit 1.0, my expectation would be that things remain fairly stable from that point onwards in terms of a 2.0 being compatible with 1.0 apps.

[John Griffin]

Max,

From a dedicated Swiz user I have to say that is one of the best and most justifiable rants I've heard in a looong time. Everybody, just get real.

John G

John Griffin
Senior Software Engineer
Overstock.com

http://thediningphilosopher.blogspot.com/
Hibernate Search in Action (http://www.manning.com/bernard/)
__________________________________
Refactoring is NOT a substitute for design.

[Adrocknaphobia]

Sorry for the delay with my response, but I've been traveling on Tokyo this week talking to businesses about the Flash Platform. I feel partially obligated to provide a response as I've recently added my support to his project as the Community Manager.

1. The only framework Adobe officially endorses for the Flash Platform is Flex. While members of Adobe Consulting might have created Cairngorm (prior to joining Adobe), it's far from a universal endorsement. I'm part of the Flex management team and I believe Swiz provides the best foundation for building enterprise Flex applications. If your boss would feel more comfortable using an Adobe recommended framework, I would be happy to send him an email offline about Swiz. ;-)
   
   
2. The "1.0" version is extremely important. I completely understand the hesitation to use a framework that has not yet met the 1.0 milestone. In fact, when I first met Chris Scott (a swiz author) it was to petition him to release a 1.0 version his popular spring framework for ColdFusion. At the time I was working for a large government organization and we shared the same policy regarding 1.0 releases.
   
   The are 2 fundamental reasons why a "1.0" matters. First, it signifies a stable API. Until 1.0 the Swiz team reserves the right to make dramatic changes that might break backward compatibility with previous versions. It's completely valid concern of management to standardize on a framework before it reaches this level.
   
   However, software frameworks are not the same as shrink-wrapped software. I think it's a unrealistic requirement to be able to 'upgrade' the core framework during your software development cycle. Even if the APIs remain intact, you have to fundamentally change your applications code to leverage the new features. If you build an application today, you might need to implement your own solution for executeServiceCall(). It would be extremely unproductive to go back and upgrade your application to use executeServiceCall() just because it was introduced in a recent version (especially since it would have zero impact on your end users).
   
   Secondly, "1.0" is a very special milestone for a all software. Many projects never reach 1.0. Especially in the world of open source software, there and probably hundreds of thousands of project on Google Code and SourceForge that are sub 1.0. The author may have lost interest in the project, or maybe it failed to gain community support. In many ways, "1.0" is symbolic of success and can be a strong guarantee of the long-term viability of project. However, if the team decided to ceremoniously move Swiz to 1.0 status just for the sake of adoption, then it would detract from such symbolism. The Swiz Team is making the right decision to stick to their roadmap for 1.0 to maintain the credibility of the project.
   
   
3. When researching frameworks and other embedded technology, you should be comparing them against stability and features, not version numbers. I honestly don't think people are actually doing that here, but the way some of the emails were written, it could be interpreted that way. Swiz is an open source framework written in AS3. If the framework has the features you need, then it shouldn't matter what features will be added next year (or even if there was to be another release). Afterall, you have the ability to fix bugs and maintain your own fork. If you are looking to standardize your team on a framework, then you should be concerned with the amount of documentation. As you can see, there are other factors that should be prioritized before a version number, which is why this thread might have caused a bit of contention.
   
   
4. A road map w/ dates is extremely important but not a requirement. When Swiz 1.0 is released, the team will also release a longer-term road map with a schedule. At least, that is what I'll urge the team to do from a community manager's perspective. I think that we'll focus some of our efforts towards increasing adoption once we reach 1.0.
   
   
5. So while we've debated the merits of the necessity of a 1.0, it is just around the corner. 1.0 alpha has been released. So just bear with us.

-Adam

[Jason Crist]

Hellz yea.  Thanks Adam for chiming in.  Adds a nice bit of closure to the whole conversation.  Well put.  I think that should make everybody happy that got fired up.

Jason Crist

[steven marcus]

http://semver.org/

attempts to standardise what version number represent in terms of api
compatibility expectations.

In summary, 1.0.0 signals that there will be no more incompatible
public API changes in the 1.x series...
This is a valuable signal if projects adopt and adhere to the
convention.

S

[Ben Clinkinbeard]

Thanks for the link Steven, we will definitely take a closer look at
that.

Ben

[wasitim]

Good lord,

The swiz team has done a great job building a great framework, on
their own time, while having to work their full time jobs I'm sure.

I am once again so glad I no longer work in the corporate world after
reading these discussions.
The mindless bureaucrats who call themselves technical architects,
technology director, blah blah blah, who serve no purpose except to
cash a paycheck and lack any technical knowledge or vision, make me
sick. If the boss has to have a 1.0 release then it's time to move on
and choose one of the myriad other frameworks out there. But give
these guys a break. No one using the great stuff they've done is
paying them for their time.

Reminds me of a line from "A Few Good Men"
'..I have neither the time nor the inclination to explain myself to a
man who rises and sleeps under the blanket of the very freedom I
provide, then questions the manner in which I provide it! I'd rather
you just said thank you and went on your way. Otherwise, I suggest you
pick up a weapon and stand a post. Either way, I don't give a damn
what you think you're entitled to!'

Heck, download the source and build a rev and call it 1.0! It isn't
like any of the upper level geniuses are going to investigate.

On Dec 10, 10:31 am, Borek <bor...@gmail.com> wrote:
> Hi Ben,
>

> what seems like a preference issue to you (you, personally, don't
> think version numbers are important) is a decisive factor for some of
> us. We need v1.0 for our bosses, simple as that. What you have now is
> some alpha that will be in development for months. I'm sorry to say
> that but Swiz 0.6.4 or Swiz 1.0 alpha is about as good as no Swiz from
> my boss's point of view. And that's a big shame.
>
> Please reconsider the versioning issue. If you rename 0.6.4 to 1.0 and
> provide an explanation no one will blame you. Java has been renamed
> from 1.5 to 5, several .NET technologies jumped from v1 to v4, it's
> nothing uncommon in software development world if it's for a good
> reason. And what reason can be better than having more Swiz developers
> out there :)
>
> Regards,
> Borek

[Adrian Pomilio]

I second your sentiments.  Version numbers are only in place so developers can be sure what version of the code they are working on or with.  Otherwise a version number is about as useful as 'tits on a water barrel' (something my hs basketball coach would say, still don't know what it means).

Take the advice, download compile and call it v1 and slap it on the bosses desk.

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=en.

--
Regards,
Adrian Pomilio
-------------------------
blog: http://www.uiandtherest.com
Youth Lacrosse: http://www.lacrossetech.com
Mens Lacrosse: http://www.raleighlacrosseclub.com
Lacrosse Forums: http://www.nclaxforums.com
Charitable Association: http://www.stickittocancer.org
Adobe User Group: http://www.triangleuserexperience.org
-------------------------------------------------------
Please consider the environment before printing this email.

[Jonathan Doklovic]

If you're of the opinion that version number don't matter, then you've
never worked in a large corporate environment where everything that
gets installed goes through a sysadmin team which will want to test on
a dev environment and then qa, and then production. Further more, most
of the sysadmin teams i know will not install any alpha or beta
software on production machines without someone from way high up
giving approval.

That being said, version numbers are not arbitrary and if used
properly can easily inform consumers of your library if a new version
is going to break anything in their app.
These two articles essentially say the same thing and is pretty much
the accepted versioning scheme in the java world.

http://wiki.eclipse.org/Version_Numbering
http://apr.apache.org/versioning.html

I'm guessing the lack of a simple change list (i.e. release notes) for
each version of swiz has to do with the fact that a lot of you feel
version numbers don't mean anything.

Don't get me wrong, I absolutely think Swiz is a great framework, but
I agree that versioning and release notes are important things to get
cleaned up.

[Jason Crist]

Ha ha ha.  It makes me laugh that this is still getting comments.

By the way, and just barely related:  Swiz 1.0 Alpha is KICKING ASS.

Jason Crist

--
You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.

To unsubscribe from this group, send email to swiz-framewor...@googlegroups.com.

[Paul Andrews]

Jason Crist wrote:
> Ha ha ha. It makes me laugh that this is still getting comments.

Well they still have a point..

> <mailto:swiz-fr...@googlegroups.com>.

> To unsubscribe from this group, send email to
> swiz-framewor...@googlegroups.com

> <mailto:swiz-framework%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/swiz-framework?hl=en.
>
>
>
>
>

> ------------------------------------------------------------------------

[Adam Murray]

We don't care so much about the version number. My bosses are
wondering where Swiz is already being used in production environments.
In other words, how proven is this framework? I'm sold after building
a prototype with it, but it will be good to have some evidence that
things will go smoothly when we deploy it on a live website.

I see a few people on this group mentioning they've been using Swiz in
production. If anyone's willing to share a little more info, it would
be great if the Swiz FAQ had a "Who's using it?" section that listed
some company names / websites. It could help offset this version
number < 1.0 concern.

Adam

[Ben Clinkinbeard]

@Jason

Hehe, glad you are enjoying 1.0 so far. Definitely more good things to
come soon. I was hoping this thread was over too, but I guess if
people still want to talk about it that is fine.

@Adam

I'd love to have a section like that on the site. I think the most
common issue though is that most enterprise projects sit behind the
firewall and are pretty confidential. I can tell you that Universal
Mind is using it/has used it on multiple enterprise-scoped projects.
Maybe we should put out a call for testimonials?

Ben

[Adrocknaphobia]

We should definitely put out a call for testimonials (to be included in the new site). However, not only for case studies, it can simply be a company list. Can UM really not even share the name of the company? Are any of the companies listed here have a swiz powered application?

http://www.universalmind.com/portfolio/

-Adam

[Ben Clinkinbeard]

Those specific projects did not use Swiz. Our adoption of Swiz has
accelerated over the last nine months or so, and most of those
projects were either complete or already in progress back then. I will
definitely see about what info we might be able to share.

Ben

On Jan 14, 5:17 pm, Adrocknaphobia <adrocknapho...@gmail.com> wrote:
> We should definitely put out a call for testimonials (to be included in the
> new site). However, not only for case studies, it can simply be a company
> list. Can UM really not even share the name of the company? Are any of the
> companies listed here have a swiz powered application?
>
> http://www.universalmind.com/portfolio/
>
> -Adam
>
> On Thu, Jan 14, 2010 at 3:23 PM, Ben Clinkinbeard <
>

> > swiz-framewor...@googlegroups.com<swiz-framework%2Bunsu...@googlegroups.com>

[Chris Scott]

I can tell you that one of the largest applications we have ever done
is currently putting together a migration plan to Swiz

Sent from my iPhone

On Jan 14, 2010, at 9:23 PM, Ben Clinkinbeard <ben.clin...@gmail.com
> wrote:

>>> fram...@googlegroups.com.

[Jason Crist]

I sure wish I could show off some of the apps that I have built using Swiz.  Unfortunately that's not an option.  I totally understand and agree with the decision, but I can't show 'em off.  Nor can I say "Company I work for uses Swiz".  I'm sure it would help others out; it would have helped me out.  But big companies have all those rules and stuff.

-JC