As a general rule any feature/API from 1.3 that you are using in 1.4
should work on /trunk -- any chances to this are always in CHANGES.txt
The place were you get in to murky water is with new features/API
since the previous release -- in this case, you will need to follow
the JIRA issues to have a sense of how "stable" the specific feature is.
On May 14, 2009, at 5:25 PM, Eger, Patrick wrote:
Fair enough, any yes we would definitely do extensive testing before
any
release. I think the problem is, that without any "official
blessing" I
as a user have no real way of knowing the current state of TRUNK. IE
is
some feature in the middle of a rework? Is there some kind of janky
partially-solved issue that is "known"? Questions like that make it
difficult for me to know where to spend my (limited) testing time,
so in
the end I really end up not doing it at all. I'd likely be able to
commit to RC X testing or monthly blessed snapshot kind of thing
though,
which is why I mention it. Only speaking for myself but I surmise
others
might be in the same boat. Again though, thanks for the great product!
Best Regards,
Patrick
-----Original Message-----
From: Grant Ingersoll [mailto:[email protected]]
Sent: Thursday, May 14, 2009 11:33 AM
To: [email protected]
Subject: Re: Solr 1.4
I'm not suggesting you don't validate it first with your own
tests. I
can't imagine you take a release and just deploy it in production,
right?
I'm just observing that if everyone (besides the committers) takes
this "release only" approach, then you quickly realize that the large
majority of testing in real production systems happens _after_
release, not before, which makes it seem less like a "release" and
more like a "release to QA". We committers and contributors make
best
efforts to test, but the community is responsible for finding most
issues simply (b/c of sheer volume) regardless of what name you want
to apply to the actual bits they are testing (i.e. nightly/release/
Giant Ball of Solr Fun). In other words, if you are planning on
upgrading to 1.4, then you should be trying out 1.4-dev in your test
environment before release, not after.
Just my two cents,
Grant
On May 14, 2009, at 12:35 PM, Eger, Patrick wrote:
Yeah, at least for us, the corporate overlords (and our operations
team) would be *extremely* hesitant to go to production with any
kind of snapshot release. If there was a "weekly stable" or similar
that might be slightly better, but definitely not a CI/nightly.
Best Regards,
Patrick
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Noble Paul ??????? ??????
Sent: Thursday, May 14, 2009 5:55 AM
To: [email protected]
Subject: Re: Solr 1.4
The advantage is that there is strength in numbers. There will be a
lot of users using the release build and if there is an issue the
user
can rest assured that there will others who need the same fix on
the
same revision. (so a better chance of a resolution)
moreover there won't be any half baked fixes in a release
On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll
<[email protected]>
wrote:
On May 13, 2009, at 7:04 PM, Eger, Patrick wrote:
+2
This would be very much appreciated by your users, I at least was
expecting March :-) We were hoping to release with 1.4
(specifically
for
java replication and field collapsing) but had to redo some plans
since
it seemed to keep slipping.
It's not like anything all that magical necessarily happens with a
release.
Sure, we package up the bits and there is some legal
ramifications, I
suppose, but the software is more or less the same. In other
words,
most
people should be fine with trunk, or some recent revision. In fact
if
more
people tried out trunk, it would be faster to release b/c we would
have
more
vetting done.
Not complaining, just FYI on our experiences
(it's a free product after all). A 4-6 month release schedule
would be
ideal for us, whereas it looks like it'll be ~9-10 months
currently?
Again, not complaining, just trying to get SOLR into production!
http://wiki.apache.org/solr/HowToContribute ;-)
