Loading...
 

Tikiwiki-devel (mailman list mirror)


You are viewing a reply to release.php  

release.php

posts: 759 Canada

Hi luci

I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.

Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):

Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.

It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.

I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.

Brendan



> On May 19, 2017, at 5:28 AM, luciash <luci@tiki.org> wrote:
>
> Hi Brendan,
>
> thanks for your hard work! Well done! I have just a little objection about the “The release process now makes a export of the working copy” change.
>
> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>
> Just my 2c.
>
> luci
>
> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>
>
> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>
>> Its mostly just a straightforward port, but there are a few differences.
>>
>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>
>> A few other minor changes including:
>> Better error checking
>> Better error reporting
>> Better archive compression
>> .tar.gz and .tar.bz2 now preserve file permissions
>> Stripping of .gitignore (and similar files) was extended
>> OSX tested and ready
>>
>> Anyone who would like to test please do. Be sure to run with —no-commit option :-)
>>
>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>
>> Brendan
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
>>
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net <mailto:TikiWiki-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel <https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 3231 United Kingdom


Oops, replied to the other list about this, should be doing the proper discussion here - just wanted to add i think /bin should not ever be in the release packages, surely not something you want on a production server?

jb




> On 19 May 2017, at 14:33, Brendan Ferguson <drsassafras@gmail.com> wrote:
>
> Hi luci
>
> I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.
>
> Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):
>
> Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.
>
> It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.
>
> I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.
>
> Brendan
>
>
>
>> On May 19, 2017, at 5:28 AM, luciash <luci@tiki.org> wrote:
>>
>> Hi Brendan,
>>
>> thanks for your hard work! Well done! I have just a little objection about the “The release process now makes a export of the working copy” change.
>>
>> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>>
>> Just my 2c.
>>
>> luci
>>
>> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>>
>>
>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>>
>>> Its mostly just a straightforward port, but there are a few differences.
>>>
>>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>>
>>> A few other minor changes including:
>>> Better error checking
>>> Better error reporting
>>> Better archive compression
>>> .tar.gz and .tar.bz2 now preserve file permissions
>>> Stripping of .gitignore (and similar files) was extended
>>> OSX tested and ready
>>>
>>> Anyone who would like to test please do. Be sure to run with —no-commit option :-)
>>>
>>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>>
>>> Brendan
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites,
>>> Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>> ___
>>> TikiWiki-devel mailing list
>>>
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 759 Canada

I think /bin in general is not included in release packages. A quick look at it reveals it might not even be needed any more. I will take another quick look and if there is no obvious reason why it should stay, will strip it from the production release packages.

Brendan

> On May 20, 2017, at 7:41 AM, Jonny Bradley <jonny@tiki.org> wrote:
>
>
> Oops, replied to the other list about this, should be doing the proper discussion here - just wanted to add i think /bin should not ever be in the release packages, surely not something you want on a production server?
>
> jb
>
>
>
>
>> On 19 May 2017, at 14:33, Brendan Ferguson <drsassafras@gmail.com> wrote:
>>
>> Hi luci
>>
>> I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.
>>
>> Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):
>>
>> Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.
>>
>> It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.
>>
>> I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.
>>
>> Brendan
>>
>>
>>
>>> On May 19, 2017, at 5:28 AM, luciash <luci@tiki.org> wrote:
>>>
>>> Hi Brendan,
>>>
>>> thanks for your hard work! Well done! I have just a little objection about the “The release process now makes a export of the working copy” change.
>>>
>>> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>>>
>>> Just my 2c.
>>>
>>> luci
>>>
>>> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>>>
>>>
>>>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>>>
>>>> Its mostly just a straightforward port, but there are a few differences.
>>>>
>>>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>>>
>>>> A few other minor changes including:
>>>> Better error checking
>>>> Better error reporting
>>>> Better archive compression
>>>> .tar.gz and .tar.bz2 now preserve file permissions
>>>> Stripping of .gitignore (and similar files) was extended
>>>> OSX tested and ready
>>>>
>>>> Anyone who would like to test please do. Be sure to run with ―no-commit option :-)
>>>>
>>>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>>>
>>>> Brendan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world’s most
>>>> engaging tech sites,
>>>> Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>> ___
>>>> TikiWiki-devel mailing list
>>>>
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 1900

Now I see there is also symlink to minifycss and minifyjs vendor_bundled
scripts in the bin/ on my svn repository copy.

Not sure when they are called...

luci


On 20.5.2017 20:41, Dr. Sassafras wrote:
> I think /bin in general is not included in release packages. A quick look at it reveals it might not even be needed any more. I will take another quick look and if there is no obvious reason why it should stay, will strip it from the production release packages.
>
> Brendan
>
>> On May 20, 2017, at 7:41 AM, Jonny Bradley <jonny@tiki.org> wrote:
>>
>>
>> Oops, replied to the other list about this, should be doing the proper discussion here - just wanted to add i think /bin should not ever be in the release packages, surely not something you want on a production server?
>>
>> jb
>>
>>
>>
>>
>>> On 19 May 2017, at 14:33, Brendan Ferguson <drsassafras@gmail.com> wrote:
>>>
>>> Hi luci
>>>
>>> I made a lengthy reply to Jonnys similar objection. Im willing to go ether way on this, but imho think it would be a mistake in the long run to continue using the tag. Im copying my reasoning here.
>>>
>>> Also note, were not talking about using a working copy. Its still an svn export, so accidental changes won’t appear there….. and even if they did, moments previously there was a check that the contents were identical…. And they should be working from a fresh checkout anyhow….. now my reply to jonny (in commit list):
>>>
>>> Its a svn export that is created, not a copy of the svn working copy. Part of the release process is making a fresh checkout. So a fresh copy has already recently been created minutes beforehand. In addition to that there has already been previous SVN checks that confirm the contents are identical. So I’m not sure where the risk is, and I haven’t been able to find any down sides. There is however logistical gains, (not just speed). Since a tag has to be created beforehand (a commit made) is difficult to make a release without first tagging. This caused 2 (not so great) workarounds in the current script. 1. the invention of the (pre) pretext, that instead of creating a export from a tag, creates a export from HEAD. This can be altogether eliminated simplifying the entire process and making it more accessible. The second issue is that tagging has to occur before the packaging starts, with is an issue, before it would actually be better to move the secdb creation to just before the tarballs are created. (would solve a number of issues) This of course is imposable if the tags are created beforehand. It also means whoever creates the tarballs has to do so speculatively. By taking the svn export from the revision number of the current working copy, it would be posable to generate the tarballs (wait for the release process to complete), and then tag (which is creating a symlink for the revision number of the current working copy). That way whoever is performing the release can be at least somewhat confidant that the tag was made properly the first time around.
>>>
>>> It looks to me like the idea of creating a export from a tag is a legacy of when the .sh script was separate. The idea of generating the svn export from the tag while the release process is completed from the external script makes more sense to me now that the release process is integrated.
>>>
>>> I suppose we could integrate a process where instead of relying on the user first generate a fresh working copy, part of the release could do is create a fresh checkout and then work from that. It might not be a bad idea, cause its suppose to be happening already anyhow.
>>>
>>> Brendan
>>>
>>>
>>>
>>>> On May 19, 2017, at 5:28 AM, luciash <luci@tiki.org> wrote:
>>>>
>>>> Hi Brendan,
>>>>
>>>> thanks for your hard work! Well done! I have just a little objection about the “The release process now makes a export of the working copy” change.
>>>>
>>>> It sounds a bit concerning to me as we do not see what the release person might have modified on his/her local copy (presumably accidentally) as opposed to what was commited and where we have more eyballs on it thanks to svn notifications... So there might be something like debugging stuff accidentally released in the tarball e.g.?
>>>>
>>>> Just my 2c.
>>>>
>>>> luci
>>>>
>>>> PS: about the Q I am not sure but I think there was some usage for it to symlink lessc there? Dunno if it is intended just for developers or end users too.
>>>>
>>>>
>>>>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>>>> So I’ve rewritten tikirelease.sh in php, and increased it into release.php. Release.php called tikirelease.sh, it was never called directly.
>>>>>
>>>>> Its mostly just a straightforward port, but there are a few differences.
>>>>>
>>>>> The release process now makes a export of the working copy (at its revision number) instead of taking the revision number of a specific tag. This should bring more flexibility into the script (if its ever needed) and at the same time simply the release process.
>>>>>
>>>>> A few other minor changes including:
>>>>> Better error checking
>>>>> Better error reporting
>>>>> Better archive compression
>>>>> .tar.gz and .tar.bz2 now preserve file permissions
>>>>> Stripping of .gitignore (and similar files) was extended
>>>>> OSX tested and ready
>>>>>
>>>>> Anyone who would like to test please do. Be sure to run with ―no-commit option :-)
>>>>>
>>>>> Q- I see that our packages have been including /bin (in tiki root), is this something that we need in our releases or would it be better to strip it?
>>>>>
>>>>> Brendan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world’s most
>>>>> engaging tech sites,
>>>>> Slashdot.org! http://sdm.link/slashdot
>>>>>
>>>>>
>>>>> ___
>>>>> TikiWiki-devel mailing list
>>>>>
>>>>> TikiWiki-devel at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world’s most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>>>> TikiWiki-devel mailing list
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


posts: 1900

Thank you for your lengthy explanation. It makes sense now to me and
looks good.

luci


On 19.5.2017 15:33, Brendan Ferguson wrote:
> Hi luci
>
> I made a lengthy reply to Jonnys similar objection. Im willing to go
> ether way on this, but imho think it would be a mistake in the long
> run to continue using the tag. Im copying my reasoning here.
>
> Also note, were not talking about using a working copy. Its still an
> svn export, so accidental changes won?t appear there?.. and even if
> they did, moments previously there was a check that the contents were
> identical?. And they should be working from a fresh checkout anyhow?..
> now my reply to jonny (in commit list):
>
> Its a svn export that is created, not a copy of the svn working copy.
> Part of the release process is making a fresh checkout. So a fresh
> copy has already recently been created minutes beforehand. In addition
> to that there has already been previous SVN checks that confirm the
> contents are identical. So I?m not sure where the risk is, and I
> haven?t been able to find any down sides. There is however logistical
> gains, (not just speed). Since a tag has to be created beforehand (a
> commit made) is difficult to make a release without first tagging.
> This caused 2 (not so great) workarounds in the current script. 1. the
> invention of the (pre) pretext, that instead of creating a export from
> a tag, creates a export from HEAD. This can be altogether eliminated
> simplifying the entire process and making it more accessible. The
> second issue is that tagging has to occur before the packaging starts,
> with is an issue, before it would actually be better to move the secdb
> creation to just before the tarballs are created. (would solve a
> number of issues) This of course is imposable if the tags are created
> beforehand. It also means whoever creates the tarballs has to do so
> speculatively. By taking the svn export from the revision number of
> the current working copy, it would be posable to generate the tarballs
> (wait for the release process to complete), and then tag (which is
> creating a symlink for the revision number of the current working
> copy). That way whoever is performing the release can be at least
> somewhat confidant that the tag was made properly the first time around.
>
> It looks to me like the idea of creating a export from a tag is a
> legacy of when the .sh script was separate. The idea of generating the
> svn export from the tag while the release process is completed from
> the external script makes more sense to me now that the release
> process is integrated.
>
> I suppose we could integrate a process where instead of relying on the
> user first generate a fresh working copy, part of the release could do
> is create a fresh checkout and then work from that. It might not be a
> bad idea, cause its suppose to be happening already anyhow.
>
> Brendan
>
>
>
>> On May 19, 2017, at 5:28 AM, luciash <luci@tiki.org
>> <mailto:luci@tiki.org>> wrote:
>>
>> Hi Brendan,
>>
>> thanks for your hard work! Well done! I have just a little objection
>> about the “The release process now makes a export of the working
>> copy” change.
>>
>> It sounds a bit concerning to me as we do not see what the release
>> person might have modified on his/her local copy (presumably
>> accidentally) as opposed to what was commited and where we have more
>> eyballs on it thanks to svn notifications... So there might be
>> something like debugging stuff accidentally released in the tarball e.g.?
>>
>> Just my 2c.
>>
>> luci
>>
>> PS: about the Q I am not sure but I think there was some usage for it
>> to symlink lessc there? Dunno if it is intended just for developers
>> or end users too.
>>
>>
>>
>> On 05/19/2017 05:57 AM, Brendan Ferguson wrote:
>>> So I?ve rewritten tikirelease.sh in php, and increased it into
>>> release.php. Release.php called tikirelease.sh, it was never called
>>> directly.
>>>
>>> Its mostly just a straightforward port, but there are a few differences.
>>>
>>> The release process now makes a export of the working copy (at its
>>> revision number) instead of taking the revision number of a specific
>>> tag. This should bring more flexibility into the script (if its ever
>>> needed) and at the same time simply the release process.
>>>
>>> A few other minor changes including:
>>> Better error checking
>>> Better error reporting
>>> Better archive compression
>>> .tar.gz and .tar.bz2 now preserve file permissions
>>> Stripping of .gitignore (and similar files) was extended
>>> OSX tested and ready
>>>
>>> Anyone who would like to test please do. Be sure to run with
>>> ?no-commit option :-)
>>>
>>> Q- I see that our packages have been including /bin (in tiki root),
>>> is this something that we need in our releases or would it be better
>>> to strip it?
>>>
>>> Brendan
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world’s most
>>> engaging tech sites,Slashdot.org <http://Slashdot.org>!http://sdm.link/slashdot
>>>
>>>
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world’s most
>> engaging tech sites, Slashdot.org <http://Slashdot.org>!
>> http://sdm.link/slashdot_
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> <mailto:TikiWiki-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world’s most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.