Yes, we should probably keep things separate. I described an approach
here, which I think is probably the simplest way to add what ASF requires:
https://lists.apache.org/thread/z51r3jdtr6djvoyfr71dml4otw7cophw
With that, there would just be a single vscode.md file at this URL:
https://daffodil.apache.org/vscode/
That page could describe the vscode extension (e.g. what it is, where
the source is, how to install, etc.) and list all the releases.
That page would also link to all the individual release pages (generated
from .md files in a _vscode directory) for each release, for example:
https://daffodil.apache.org/vscode/1.0.0
Unfortunately, this approach doesn't really allow extra vscode related
sub pages. For example, if you wanted something like
https://daffodil.apache.org/vscode/foo
If you think we might need something like that, you'll still want the
same vscode.md file as the root, but could add some subdirectories to
get something like this specifically for vscode releases:
https://daffodil.apache.org/vscode/releases/
https://daffodil.apache.org/vscode/releases/1.0.0
That adds some extra complication--I'm not sure it's needed or not.
- Steve
On 3/22/22 8:44 PM, Shane Dell wrote:
Steve, in regard to updating daffodil site should I create a separate folder
under site like `_releases_vscode` so that we can keep the releases READMEs for
daffodil and daffodil-vscode separated to keep it more organized? Or how do you
think would be best to separate those from each other?
On 2022/03/22 20:35:59 Mike Beckerle wrote:
I am changing my vote to +1. It now seems to be working as designed, and
looks useful. Yay.
My challenges here have been related to installation, reinstallation, etc.
Clearing out the RC1 to get the RC2 to work was non-trivial, but can be
easily addressed in doc short term.
However, while I am in favor of a release, since Daffodil 3.3.0 is now out,
if Daffodil is built into the vscode debugger, then we really do need to
upgrade it now.
My testing included verifying GPG signatures and sha512 sums, installing
the VSIX file, and debugging the EDIFACT DFDL schema which is spread across
4 schema files.
Are there draft pages about this vscode debugger release on the daffodil
site?
On Fri, Mar 18, 2022 at 3:35 PM Mike Beckerle <[email protected]> wrote:
Since this vote closes sunday, and I won't have further test time before
then, I have to vote now.
Voting -1
I couldn't get the convenience binary .vsix file to work to debug EDIFACT
with a breakpoint in the 2nd file of the schema.
I went so far as to uninstall the older extension, shut down vscode,
manually purge the daffodil extension from ~/.vscode/extensions, the
restart vscode and install the new downloaded .vsix file. Verify
~/.vscode/extensions now has the extension in it again.
So I am definitely installing and running the vsix from the
dist.apache.org site for rc2. Something must be wrong with it.
My next step would be to build my own vsix from source, but I don't have
time before the Sunday end of vote.
On Thu, Mar 17, 2022 at 3:06 PM Shane Dell <[email protected]> wrote:
Hello all,
Ignore the last vote as I did not change my email to the proper one
registered for apache.
I'd like to call a vote to release Apache Daffodil VS Code 1.0.0-rc2.
All distribution packages, including signatures, digests, etc. can be
found at:
https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.0.0-rc2/
This release has been signed with PGP key
86DDE7B41291E380237934F007570D3ADC76D51B, corresponding
to [email protected], which is included in the KEYS file here:
https://downloads.apache.org/daffodil/KEYS
The release candidate has been tagged in git with 1.0.0-rc2.
For reference, here is a list of all closed GitHub issues tagged with
1.0.0:
https://github.com/apache/daffodil-vscode/issues?q=is%3Aissue+is%3Aclosed+is%3A1.0.0
Please review and vote. The vote will be open for at least 72 hours
(Sunday, 17 March 2022, 12 Noon EST).
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Thank you,
- Shane Dell
