<div dir="auto">Yes, I can tell what is tested and what not:<div dir="auto">* I tried adding a new.py in all possible directories and ran sugar and sugar-runner, but I was not able to crash sugar.</div><div dir="auto">(#893)</div><div dir="auto">* Tested many non sugar-fructose activities.</div><div dir="auto">* Wasn't able to connect two local sugar computers using jabber server configuration.</div><div dir="auto">* changing ttys while sugar is running causes a glitch on the sugar xserver</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I tested more of activities than that if sugar core. The activities I reviewed are those of new pull requests, and were able to find new issues of the same. I guess until someone comes with a new PR on sugar core, I might not go in depth into it. </div><div dir="auto"><br><div dir="auto"><br></div><div dir="auto">PS: *-git packages are a mirror of the GitHub master branch of the repository as a form of package. The 0.116 tag has over 50+ issues which is fixed in PRs on the master. As we are not tracking more features or freezing a repository and fixing releases annually, the 0.116 build is exactly almost stable. </div><div dir="auto">And, I have not released a stable version since the last report to the mailing list.</div><div dir="auto"><br></div><div dir="auto">An inspirational software release system from KDE Plasma Desktop Environment:</div><div dir="auto">Plasma just released 5.18 a week ago. over the last six months, they had been testing 5.18+ by developers again and again. The important bug fixes were released as release candidates. This is beneficial in two fold: Users find issues in 5.17 and report it, and developers try to make 5.18 the best before releasing it for public use. Currently they are testing 5.19 with more features but unstable.</div><div dir="auto"><br></div><div dir="auto">Is it possible to implement this versioning in sugar core repositories shortly. I am not sure if this is currently possible, or if this method is already tried, but I am putting it in the mailing list for reconsideration (if any)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020, 23:34 James Cameron <<a href="mailto:quozl@laptop.org" target="_blank" rel="noreferrer">quozl@laptop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sounds great.<br>
<br>
Release of next Sugar depends on test results.  While I've made some<br>
of my own testing, I've heard almost nothing from anyone else.  Could<br>
you please tell us what testing you've done on Arch?<br>
<br>
I'm not asking for issues, I'm asking for what works.<br>
<br>
On Thu, Mar 12, 2020 at 09:41:13PM +0300, Srevin Saju wrote:<br>
> Released to the Arch User Repository<br>
> * gwebsockets-git (0.7+git)<br>
> * sugar-artwork-git  (0.116+git)<br>
> * sugar-datastore-git  (0.116+git)<br>
> * sugar-git  (0.116+git)<br>
> * sugar-runner-git  (0.110+git)<br>
> * sugar-toolkit2-gtk3-git  (0.116+git) <br>
> * sugar-toolkit-gtk3-git  (0.116+git)<br>
> <br>
<br>
> _______________________________________________<br>
> Sugar-devel mailing list<br>
> <a href="mailto:Sugar-devel@lists.sugarlabs.org" rel="noreferrer noreferrer" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
<br>
-- <br>
James Cameron<br>
<a href="http://quozl.netrek.org/" rel="noreferrer noreferrer noreferrer" target="_blank">http://quozl.netrek.org/</a><br>
</blockquote></div>