You mention a VSIX + ZIP? What is the zip you reference? Is that the
source, or are there two convenience binaries that make up an extension?
The license/notice stuff all needs to be fixed before we start the
process. This also includes enabling Apache Rat to ensure all files are
licensed correctly. (Issues #23)
I think the README needs to be updated to clarify how to build and
install from source. As part of the vote process, I'm going to want to
build/run from source, etc., so clear instructions on that are
important. (Issue #23)
I know the incubator has had some concerns about releases going to
GitHub in the past. Releases are not official until they pass a VOTE, so
publishing anything to GitHub that hasn't gone through that vote that
might look like a release should be avoided.
So I would recommend that we don't even use an automated release process
with GitHub actions, and not even using GitHub for storing releases. It
might simplify things, but Apache requires more to releases than
creating source tarballs and and convenience binaries. They must be
uploaded to dist.apache.org, there must be signatures, and checksums,
etc. GitHub actions doesn't have the KEYS/authentication to do that
step. If we want to upload things to GitHub releases once things pass,
that's probably okay, but anything else probably doesn't follow ASF
guidelines.
For Daffodil, we created a container to build release candidates that
automates much of this and ensures repeatable builds. The instructions
for Daffodil are here:
https://cwiki.apache.org/confluence/display/DAFFODIL/Release+Workflow
It might make sense to do something similar for vscode.
And related to tags/builds, note that there should never be a new build
created for the final release tag. When an release candidate vote
passes, the process to make that an official release should just be
renaming the release candidate artifacts to remove the rcX in the
filename, and then add a tag to the repo. This ensures what passed the
vote is what is actually released.
I would also suggest we figure out how to publish to the marketplace--do
we need something from INFRA?. I also wonder if there is some sort of
staging thing? This could allow testing the marketplace without
officially publishing, like we do with daffodil jar releases. This can
of course be done after a release, so maybe isn't worth holding things
up, but it would be nice to figure this out sooner rather than later.
On 10/13/21 11:12 AM, John Wass wrote:
Status on Mike's original list
1-4 complete
We have some tweaks that could be added for a 1.0.0, but perhaps we get an
1.0.0-RC1 out ASAP, and then can improve that with further RCs?
Blockers for an initial RC right now might be
1. Do we know the ASF process for releasing the VSIX and zip to GitHub?
2. Add the actions CI back in for automated release from a tag.
3. Items 5-7 of Mike's original list ?
Sound right?
On Thu, Oct 7, 2021 at 10:23 AM Mike Beckerle <mbecke...@apache.org> wrote:
+1 on summary + linking to older issue
On Thu, Oct 7, 2021 at 10:15 AM Steve Lawrence <slawre...@apache.org>
wrote:
+1 sounds good to me
On 10/7/21 10:14 AM, John Wass wrote:
Sounds good. I will do that and start to move issues over.
Some of these issues have multiple posts by multiple authors and it
will
be
hard to capture all that context in the new repo. I'm thinking of
generating a summary and then adding a link to the archived issue. Any
objections there?
On Wed, Oct 6, 2021 at 5:01 PM Mike Beckerle <mbecke...@apache.org>
wrote:
No problem. Go ahead. That's a sensible last commit on that repo.
On Wed, Oct 6, 2021 at 5:00 PM John Wass <jwa...@gmail.com> wrote:
Will there be any problem with updating the readme in the old repo to
note
that it is relocated?
On Wed, Oct 6, 2021 at 4:20 PM John Wass <jwa...@gmail.com> wrote:
Steps 1-7 sound good to me. Some thoughts
1) push to https://github.com/apache/daffodil-vscode repository.
Who is going to push the code?
2) move over github issues to the new repo issues
It doesn't look like the "transfer issue" function works across
orgs.
So
a manual move it shall be.
3) move wiki pages/doc to the github wiki associated with the new
repository
Same thing, manual copy. Not as significant as issue moving.
4) archive the old original github repo (for posterity).
Concur. I'd say this happens first to ensure nothing drifts while we
are
moving things around.
On Wed, Oct 6, 2021 at 10:41 AM Mike Beckerle <mbecke...@apache.org
wrote:
With the IP-clearance now complete, next steps (I think) are:
1) push to https://github.com/apache/daffodil-vscode repository.
I believe the existing repo main branch should be pushed here as
is,
i.e.,
no need to squash anything.
Note the main branch is named "main", not master.
Tag it at the current point on the main branch. (suggest tag name
apache-ip-clearance ? or happy-apache-birthday ?)
2) move over github issues to the new repo issues
3) move wiki pages/doc to the github wiki associated with the new
repository
4) archive the old original github repo (for posterity).
5) update main daffodil-site pages to mention/highlight the new
vscode
debugger and link to its issues and wiki.
6) whatever else I forgot
and....
7) start planning for release 1.0.0.
I am not sure what additional things are needed in order to meet
Apache
criteria for release, given the vscode marketplace as a means of
distribution. Perhaps we don't need to solve that yet?
I think we covered almost everything else during the IP-clearance
process.
If there are things, let's discuss them here on the dev list.
