for the user is there any difference in the access and downloading from SF vs Git? In other words is it habit or is there some kind of affordance that makes SF easier? if just habit, we can start redirecting and slowly wean people of the habit. It does seem strange to have 2 locations for releases.

 Or is there something else we should be thinking about? --e

On Wed, Jan 30, 2019 at 7:39 AM Hugh Cayless <philomousos@gmail.com> wrote:
It’s extra work, and requires a good deal of preliminary setup that newer Council members are less likely to find otherwise useful. But I note that SourceForge file releases still get more downloads still than the GitHub ones. I don’t know that most folks get copies of the releases that way, but people are clearly still using it, so I take it back :-).

> On Jan 30, 2019, at 07:14, Peter Stadler <stadler@edirom.de> wrote:
>
> Hmm, what is it that we gain by dropping releases on SourceForge?
> I thought it was a benefit to the user which does not cost us much.
>
> Best
> Peter
>
>> Am 30.01.2019 um 13:06 schrieb Hugh Cayless <philomousos@gmail.com>:
>>
>> I think in particular we should revisit the question of whether we want to continue to release on Sourceforge and to look seriously at automating releases on GitHub. I’ve been meaning to look into the latter for ages.
>>
>> H
>>
>>> On Jan 29, 2019, at 23:05, Mylonas, Elli <elli_mylonas@brown.edu> wrote:
>>>
>>> I don't have much to add - mostly that we can continue to improve the instructions for the release.
>>>
>>> Also that the process beyond the actual guidelines compilation is still very complicated and requires a great deal of special knowledge, not to mention access privileges...
>>> But it worked, once again. The Raven has spread its wings.
>>>
>>> best to all  --elli
>>>
>>>
>>>
>>> On Tue, Jan 29, 2019 at 9:22 PM Hugh Cayless <philomousos@gmail.com> wrote:
>>> Hi All,
>>>
>>> 3.5.0 wasn't entirely smooth. Remaining tasks are reloading OxGarage and Roma Docker containers (request has been sent), doing the Oxygen plugin release, and doing the Debian release. The latter process fails due to an SSL error. I suspect it may have to do with the ancient version of Ant on the TEI server and maybe wonky SSL support in an older Java library. Upgrading Ant might fix everything. I think it worked before because Jenkins wasn't under HTTPS.
>>>
>>> Notes on updates needed to the release docs are at https://docs.google.com/document/d/1fTrCQrC8tRTZWLGScXKb0R_brwhOoRA6uta4c1hCiu4/edit# . Comments welcome.
>>>
>>> We got bitten (again!) by the circular dependency between the Stylesheets and Guidelines. The Stylesheets build started failing after the Guidelines were released because it uses the p5subset from the latest release, meaning we're not *actually* testing the Stylesheets against the latest GLs build.
>>>
>>> Martin spotted a problem with the SimplePrint exemplar post release, which we decided to go back and fix. Moving the att.tableDecoration class into the figure module broke SimplePrint because it references nearly everything directly, bypassing the modules. So we inadvertently lost table attributes by putting them alongside tables (where they should have been in the first place). This is something we'll have to keep an eye out for in the future. but note https://github.com/TEIC/TEI/issues/1853.
>>>
>>> I think that was the gist of it. Overall, we've had better releases, but it wasn't too bad. Elli may have some followup if I missed anything. Thanks to everyone who helped today!
>>>
>>> Hugh
>>>
>>> _______________________________________________
>>> Tei-council mailing list
>>> Tei-council@lists.tei-c.org
>>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
>> _______________________________________________
>> Tei-council mailing list
>> Tei-council@lists.tei-c.org
>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
>
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council