I pretend to launch a beta with 2 months fixed for tests, but this beta is
just to make sure it runs smoothy on other machines, and if some servers
(that application depends on) will be ok with heavy access. If I got
problems and need more things, for sure I will launch another beta with
longer tim
On Aug 16, 2011, at 10:00 AM, Shawn Bakhtiar wrote:
> If the app date deceases, and they can not use it again, until you decide,
> find yourself another job.
Well, yes, it's your responsibility to get another release into their hands
well before the expiration date. And it's their responsibilit
ch
thing as ideal conditions. Trying to create controls, you only create more
problems.
> From: cocoa...@charlessoft.com
> Date: Mon, 15 Aug 2011 13:00:34 -0500
> To: scott_r...@elevated-dev.com
> CC: cocoa-dev@lists.apple.com
> Subject: Re: recomendations for creating a bet
On Aug 15, 2011, at 10:09 AM, Scott Ribe wrote:
> Yes, good point. The expiration date should be just to make sure that the
> next release has actually gotten installed--and I suspect that's what he
> meant, getting reports about bugs in old versions after newer ones have been
> received...
If
On Aug 15, 2011, at 8:53 AM, Charles Srstka wrote:
> If you’re giving your testers betas that are expiring by the time they’re
> sending you reports, you’ve got the expiration date set *way* too early. By
> the time a beta expires, you should have sent them a newer build long ago.
Yes, good poi
On Aug 15, 2011, at 8:55 AM, Shawn Bakhtiar wrote:
> But you are forcing your users hand, which is never a good thing. They may
> need more time, or lack the resources to continually upgrade.
>
> I tent to give users choice, and as much as possible build the app forward
> compatible (get the Mo
v@lists.apple.com
> Subject: Re: recomendations for creating a beta with date to expire
>
> At 8:35 AM -0600 8/15/11, Scott Ribe wrote:
> >Generally, but closed betas are the one case where expirations
> >really make sense. It is after all a beta, and you do not want
> >som
On Aug 15, 2011, at 3:28 AM, Ron Hunsinger wrote:
> Isn't the purpose of a beta to uncover bugs for you to track down? If a bug
> is reported the day before the beta expires, do you really want to
> self-impose a one-day time limit to track it down? Even if no one is running
> that beta, all of
At 8:35 AM -0600 8/15/11, Scott Ribe wrote:
Generally, but closed betas are the one case where expirations
really make sense. It is after all a beta, and you do not want
someone still running the beta a year after the actual release, just
because the person who was your contact for testing forg
com
> Date: Mon, 15 Aug 2011 08:35:58 -0600
> To: eezac...@xs4all.nl
> CC: cocoa-dev@lists.apple.com
> Subject: Re: recomendations for creating a beta with date to expire
>
> On Aug 15, 2011, at 8:28 AM, Izak van Langevelde wrote:
>
> > It is my experience that w
On Aug 15, 2011, at 8:28 AM, Izak van Langevelde wrote:
> It is my experience that with restricting access to your software you are
> either shooting yourself in the foot, or somebody else. Without, other people
> are shooting themselves in the foot. Personally, I prefer the latter.
Generally,
On 2011-08-15, at 3:08 AM, Charles Srstka wrote:
> On Aug 14, 2011, at 9:04 PM, Jerry Krinock wrote:
>
>> One more thing. Remember to leave some kind of back door for yourself.
>> I've wanted to punch myself in the nose when I needed to reproduce a bug
>> report and my app told me that it wo
On Aug 15, 2011, at 1:28 AM, Ron Hunsinger wrote:
>
> On Aug 15, 2011, at 12:08 AM, Charles Srstka wrote:
>> Really? Surely there are better uses of your time than trying to track down
>> an old bug in an expired beta version that people aren’t even supposed to be
>> able to run anymore.
>
>
On Aug 15, 2011, at 12:08 AM, Charles Srstka wrote:
> Really? Surely there are better uses of your time than trying to track down
> an old bug in an expired beta version that people aren’t even supposed to be
> able to run anymore.
Isn't the purpose of a beta to uncover bugs for you to track do
On Aug 14, 2011, at 9:04 PM, Jerry Krinock wrote:
> One more thing. Remember to leave some kind of back door for yourself. I've
> wanted to punch myself in the nose when I needed to reproduce a bug report
> and my app told me that it wouldn't launch because it was expired.
Really? Surely ther
On 2011 Aug 14, at 13:37, Wilker wrote:
> You have any other hints for doing this?
One more thing. Remember to leave some kind of back door for yourself. I've
wanted to punch myself in the nose when I needed to reproduce a bug report and
my app told me that it wouldn't launch because it was
The network is not a main issue, since my program is useless without network
at all.
And the idea is to people try it before it launched, in fact it will be an
closed beta, I thing I will follow the Nick mind and use local clock just
for speed up, anyway the program can be cracked anyway (easier o
I agree, and would like to add that I have done this, and did encounter an
issue where people had an expired beta and therefore couldn't use the program
until they had downloaded an update, and were annoyed by that - especially if
they were on the road and had no internet connection. Although I
On Aug 14, 2011, at 2:37 PM, Wilker wrote:
> Hi Guys,
>
> I'm thinking about releasing a beta version of my software. Im thinking
> about use the same strategy as Reeder for Mac did, betas with fixed time to
> expire.
>
> What you recommendations to make it safer? Im thinking about do an intern
19 matches
Mail list logo
