Architect 6 release + Arc 5 LTS: plans, feedback, & questions

I’m really stoked to share that within the next couple of weeks we’ll be releasing Architect 6, easily the largest set of improvements to Architect in its history. A few of the highlights:

• Provisioning and resource creation is now fully CloudFormation-based – this means AWS, not Architect, is responsible for generating your application’s resources, providing (among other things):
  • Faster, more deterministic app resource creation in many cases (especially for large changes to application infrastructure)
  • Only the cloud resources that need to exist will exist (i.e. automatic resource pruning)
  • A significantly tighter security profile and true least privilege role policies
• Architect’s core workflows are now broken out into far more maintainable independent modules (see: Sandbox, Hydrate, etc.)
• Architect Functions releases for Ruby and Python!
• New automatic service discovery layer
• Fully rewritten docs site (arc.codes branch here), including a (forthcoming) migration / upgrade guide from 5-6

While the underlying Architect project structure and .arc format will not undergo any changes with this release, the cloud infrastructure provisioning changes made by Architect 6 may have a few potentially breaking changes (which are worth getting into soon and separately). But we hope that for most folks this will a drop-in replacement.

That said, due to the nature of these changes and our desire to not break folks, we intend to place Architect 5 into LTS and continue its maintenance. (More on that below!)

A few questions we’d like your feedback on:

• Architect 6 has been in development in a separate repo at @architect/cli, but this work will need to be mainlined back into @architect/architect
  • Insofar as you have a preference, would you prefer we move Architect 5 into a separate repo (i.e. @architect/architect-5, @architect/legacy, etc.?), or maintain it in a branch of the main repo (or do something else)?
  • Considerations of separate repos vs. branches include: issues, docs, etc.
  • In terms of NPM, Architect 6 will become @architect/architect@latest, while Architect 5, wherever it lives, will continue to be published as @architect/architect@5.x
• This is the first time we’ve put a version of Architect into LTS; how long do you feel we should commit to supporting LTS releases?
• Arc 4.x was Yeti, Arc 5.x is Catalope, which cryptozoological animal shall we pick this time? (The only rule is no human-hybrids.) 👹

Of course, anything else you’d like to provide feedback on, or have us consider, we’re all ears!

---

Additional reference Arc 6 master issue https://github.com/architect/architect/issues/404 arc.codes Arc 6 master issue: https://github.com/architect/arc.codes/issues/114 arc.codes Arc 6 branch: https://github.com/architect/arc.codes/tree/v4

[ryanblock]

These are some excellent cryptids.

Ok, to briefly turn the conversation to how we handle handle Arc 5 - 6 repo transition – before returning to cryptids, ofc – having given this more thought, I think Arc 5 LTS should be transitioned into a new, separate repo.

More specifically:

• Take the current repo at @architect/architect and copy it, and all of its git history, to a new repo (for sake of conversation github.com/architect/architect-5, but open to names!)
  • Important: retain its git history!
• Overwrite github.com/architect/architect with the contents of github.com/architect/cli
  • Remove anything not present in cli, ofc
  • Ideally retain cli’s history, but not absolutely necessary imo
• Result:
  • npm @architect/architect@5.x is published from github.com/architect/architect-5
  • npm @architect/architect@latest is published from github.com/architect/architect
  • Binary dists compiled from github.com/architect/architect

Reasoning:

• Working in a long-lived branch sucks
• Minor, but this approach doesn’t laden Arc’s git history with additional work in an LTS branch that will never be merged back to master
• Eventually when we retire 5, it seems like a better choice to me to have an archived repo than a deleted branch (and all that work potentially gone forever)
• Related, a separate repo should be easier to use / refer to much later (if necessary)

Still completely amenable to other perspectives on this though!

[kborchers]

I agree that a name change would be good as the current name was chosen early in the project’s life. I would probably choose arcserverless for brevity over architectserverless but I’d be fine with either. @ryanblock I’m happy to make changes if my login still works, but in any case we should get it changed and start using it.