Re: AP v1.4.2: Dependency Building: Still Broken

--00032557620e2321f4046b3eb02a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

>
> Well, the obvious argument against it is that "stable" releases will
> be more unstable than they already are. Bigger chance of nasty bugs to
> hit end users.
>
> It will also make the introduction of large changes much harder, since
> there would be no intermediate release to put them in.
>
> That said, given the limited amount of manpower - both developers and
> testers - it maybe sane to skip the unstable release series since I
> guess very few actually tests it.


With my OSS applications, I handle this issue by tagging all new releases as
being 'beta' for a few days.  If nobody reports any significant bugs within
that time-frame, I then change the auto-update tag to 'stable' on the
website.

Jan Niklas: to help reduce these kind of problems, you should go for a
> release candidate and then Chris could've tested it by setting
> AUTOPACKAGE_RUNTIME to this new version without the release having to
> hit end users.


I think this is a good idea and it negates needing to email me the beta
source code.  I originally suggested the latter, as I wasn't aware of the
"AUTOPACKAGE_RUNTIME_VERSION" variable.

As a teacher and since the AP v1.4.1 (local) and AP v1.2.6 (remote)
combination still works, I agree that Jan should primarily concentrate on
his schoolwork.  My point wasn't "hurry up and fix", but rather "don't
release before testing" :-).

--00032557620e2321f4046b3eb02a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde=
r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le=
ft: 1ex;"><div>
</div>Well, the obvious argument against it is that &quot;stable&quot; rele=
ases will<br>
be more unstable than they already are. Bigger chance of nasty bugs to<br>
hit end users.<br>
<br>
It will also make the introduction of large changes much harder, since<br>
there would be no intermediate release to put them in.<br>
<br>
That said, given the limited amount of manpower - both developers and<br>
testers - it maybe sane to skip the unstable release series since I<br>
guess very few actually tests it.</blockquote><div><br>With my OSS applicat=
ions, I handle this issue by tagging all new releases as being &#39;beta&#3=
9; for a few days.=C2=A0 If nobody reports any significant bugs within that=
 time-frame, I then change the auto-update tag to &#39;stable&#39; on the w=
ebsite.<br>



<br><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin:=
 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote">Jan Niklas: t=
o help reduce these kind of problems, you should go for a<br>
release candidate and then Chris could&#39;ve tested it by setting<br>
AUTOPACKAGE_RUNTIME to this new version without the release having to<br>
hit end users.</blockquote><div><br>I think this is a good idea and it nega=
tes needing to email me the beta source code.=C2=A0 I originally suggested =
the latter, as I wasn&#39;t aware of the &quot;AUTOPACKAGE_RUNTIME_VERSION&=
quot; variable.<br>


<br>As a teacher and since the AP v1.4.1 (local) and AP v1.2.6 (remote) com=
bination still works, I agree that Jan should primarily concentrate on his =
schoolwork.=C2=A0 My point wasn&#39;t &quot;hurry up and fix&quot;, but rat=
her &quot;don&#39;t release before testing&quot; :-).<br>



<br></div></div></div>

--00032557620e2321f4046b3eb02a--