630 lines
23 KiB
Markdown
630 lines
23 KiB
Markdown
# Weevil Roadmap
|
|
|
|
This document outlines the planned feature development for Weevil across multiple versions. Features are subject to change based on user feedback, technical constraints, and market needs.
|
|
|
|
**Current Version:** 1.0.0-rc1
|
|
**Next Release:** 1.1.0 (Target: TBD)
|
|
|
|
---
|
|
|
|
## Version 1.1.0 - Core Stability & Team Adoption
|
|
|
|
**Theme:** Making Weevil production-ready for FTC teams with essential operational features and reducing friction in existing workflows.
|
|
|
|
### System Audit & Diagnostics
|
|
|
|
**Feature:** `weevil status` or `weevil doctor` command
|
|
|
|
**Description:** Provides a comprehensive audit of the development environment, showing what's installed and what versions are present. This would display:
|
|
- FTC SDK versions (current and available)
|
|
- Android SDK installation status and version
|
|
- Gradle version and location
|
|
- Java/JDK version and location
|
|
- ADB availability and version
|
|
- Any other critical dependencies Weevil manages
|
|
|
|
**Rationale:** Teams need visibility into their environment to troubleshoot issues. Coaches working with multiple machines need to quickly verify setup consistency across laptops. This builds trust by making Weevil's actions transparent.
|
|
|
|
**Pros:**
|
|
- Straightforward to implement - query what `weevil setup` installed
|
|
- High value for troubleshooting
|
|
- Professional tooling feel
|
|
- Helps with team onboarding (new members can verify setup)
|
|
|
|
**Cons:**
|
|
- Need to handle edge cases (partial installations, manual modifications)
|
|
- Version detection across platforms may be fragile
|
|
- Output formatting needs to be clear for non-technical users
|
|
|
|
**Priority:** HIGH - Essential for v1.1.0
|
|
|
|
---
|
|
|
|
### Dependency Cleanup
|
|
|
|
**Feature:** `weevil clean` or `weevil uninstall` command
|
|
|
|
**Description:** Removes dependencies that Weevil installed during setup. This includes:
|
|
- FTC SDK files
|
|
- Android SDK components (if Weevil installed them)
|
|
- Gradle distributions
|
|
- Configuration files Weevil created
|
|
|
|
Should offer options for selective cleanup (e.g., keep SDK but remove Gradle) or complete removal.
|
|
|
|
**Rationale:** Teams switch machines, need to free disk space, or want to start fresh. Without a clean uninstall, Weevil leaves artifacts behind. This is critical for maintaining system hygiene and building confidence that Weevil doesn't pollute the environment.
|
|
|
|
**Pros:**
|
|
- Demonstrates respect for users' systems
|
|
- Essential for testing and development
|
|
- Helps with troubleshooting (clean slate approach)
|
|
|
|
**Cons:**
|
|
- Must track what Weevil installed vs. what user installed manually
|
|
- Risk of removing shared dependencies other tools need
|
|
- Need careful confirmation prompts to prevent accidental deletion
|
|
|
|
**Priority:** HIGH - Essential for v1.1.0
|
|
|
|
---
|
|
|
|
### Corporate/School Proxy Support
|
|
|
|
**Feature:** Transparent proxy configuration for all network operations
|
|
|
|
**Description:** Automatically detect and use system proxy settings (or allow manual configuration) for all network operations including:
|
|
- Gradle dependency downloads
|
|
- Android SDK downloads
|
|
- FTC SDK downloads
|
|
- Any HTTP/HTTPS requests Weevil makes
|
|
|
|
Handle `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` environment variables and write appropriate configuration into Gradle properties, Android SDK manager config, etc.
|
|
|
|
**Rationale:** Many FTC teams work in schools or corporate environments with mandatory proxy servers. Without proxy support, Weevil is unusable in these environments, cutting off a significant portion of the potential user base.
|
|
|
|
**Pros:**
|
|
- Unlocks enterprise/school environments
|
|
- Relatively well-understood problem space
|
|
- Shows professionalism and enterprise-readiness
|
|
|
|
**Cons:**
|
|
- Proxy configurations vary widely
|
|
- Authentication (proxy username/password) adds complexity
|
|
- SSL/certificate issues in corporate environments
|
|
- Testing requires access to proxy environments
|
|
|
|
**Priority:** HIGH - Essential for v1.1.0
|
|
|
|
---
|
|
|
|
### Android Studio Integration
|
|
|
|
**Feature:** Seamless integration with Android Studio IDE
|
|
|
|
**Description:** Generate Android Studio project files and configurations that:
|
|
- Hide Weevil's internal directory structure from the IDE view
|
|
- Present a clean, minimal file tree to students
|
|
- Hook Weevil's build and deploy scripts into Android Studio's "Run" button
|
|
- Properly configure the IDE's indexing and code completion
|
|
- Support debugging integration
|
|
|
|
The goal: students work in Android Studio (the tool they know) but get Weevil's improved project structure and deployment workflow behind the scenes.
|
|
|
|
**Rationale:** This is the killer feature that bridges the gap between Weevil's better engineering practices and students' existing workflow. Kids already know Android Studio. Making Weevil "just work" with it removes adoption friction and lets them focus on robot code, not tooling.
|
|
|
|
**Pros:**
|
|
- Huge competitive advantage for Nexus Workshops
|
|
- Leverages existing student knowledge
|
|
- Reduces cognitive load (one less tool to learn)
|
|
- Makes Weevil invisible in the best way - it just works
|
|
|
|
**Cons:**
|
|
- Android Studio project file format may change
|
|
- Complex to test across different Android Studio versions
|
|
- May conflict with students' existing Android Studio customizations
|
|
- Requires deep understanding of IDE configuration
|
|
|
|
**Priority:** HIGH - Strong candidate for v1.1.0 (killer feature)
|
|
|
|
---
|
|
|
|
### Manual Installation Fallback Documentation
|
|
|
|
**Feature:** Comprehensive manual setup documentation
|
|
|
|
**Description:** Detailed, step-by-step instructions for manually installing every dependency when automation fails. This includes:
|
|
- Screenshots or terminal output examples
|
|
- Platform-specific variations (Windows vs. Linux)
|
|
- Common error messages and solutions
|
|
- Checksums for verifying downloads
|
|
- Fallback download URLs if primary sources are blocked
|
|
|
|
**Rationale:** Automation fails. Proxies block downloads. Firewalls interfere. Having a "guaranteed to work" manual path builds confidence and ensures teams aren't stuck. This is about providing an escape hatch and building trust.
|
|
|
|
**Pros:**
|
|
- Low effort (documentation, not code)
|
|
- High value when automation fails
|
|
- Educational - teaches students what's happening under the hood
|
|
- Demonstrates thoroughness and professionalism
|
|
|
|
**Cons:**
|
|
- Requires maintenance as dependencies evolve
|
|
- Screenshots go stale quickly
|
|
- Platform variations multiply documentation burden
|
|
|
|
**Priority:** MEDIUM-HIGH - Strong candidate for v1.1.0
|
|
|
|
---
|
|
|
|
### Package Distribution (Debian/Ubuntu)
|
|
|
|
**Feature:** `.deb` package for easy installation on Debian-based systems
|
|
|
|
**Description:** Create Debian packages that can be installed via `sudo dpkg -i weevil_1.1.0_amd64.deb` or distributed through a personal APT repository. Package would:
|
|
- Install weevil binary to `/usr/bin`
|
|
- Include man pages and documentation
|
|
- Handle any system dependencies
|
|
- Support clean uninstallation
|
|
|
|
**Rationale:** Provides a "professional" distribution method for Linux users. Makes Weevil feel like real software, not just a script. Easier for schools/teams to deploy across multiple machines.
|
|
|
|
**Pros:**
|
|
- Professional appearance
|
|
- Standard Linux distribution method
|
|
- Can include in deployment automation (Ansible, etc.)
|
|
- `cargo-deb` makes this relatively easy
|
|
|
|
**Cons:**
|
|
- Maintenance overhead for packaging
|
|
- Need to support multiple Ubuntu/Debian versions
|
|
- Most teams will just download the binary anyway
|
|
- Not essential for functionality
|
|
|
|
**Priority:** LOW - Nice to have, but not essential for v1.1.0
|
|
|
|
---
|
|
|
|
## Version 1.2.0 - Polish & Accessibility
|
|
|
|
**Theme:** Making Weevil accessible to non-technical users and expanding platform support.
|
|
|
|
### Windows Installer (MSI)
|
|
|
|
**Feature:** Professional Windows installer package
|
|
|
|
**Description:** Create an MSI installer using WiX Toolset or `cargo-wix` that:
|
|
- Installs weevil.exe to Program Files
|
|
- Adds weevil to system PATH automatically
|
|
- Creates Start Menu entries
|
|
- Appears in "Programs and Features" for clean uninstall
|
|
- Optionally creates desktop shortcut
|
|
|
|
**Rationale:** Windows users expect installers, not loose executables. An MSI makes Weevil feel professional and legitimate. Start menu integration makes it discoverable.
|
|
|
|
**Pros:**
|
|
- Expected Windows UX
|
|
- Automatic PATH configuration (users don't need to understand this)
|
|
- Professional appearance
|
|
- Easy deployment in school environments
|
|
|
|
**Cons:**
|
|
- MSI creation and signing has complexity
|
|
- Code signing certificates cost money ($200+/year)
|
|
- Without code signing, Windows shows security warnings
|
|
- Testing across Windows versions (10, 11)
|
|
|
|
**Priority:** MEDIUM - Polish feature for Windows adoption
|
|
|
|
---
|
|
|
|
### Linux Program Launcher Integration
|
|
|
|
**Feature:** Desktop file and menu integration for Linux
|
|
|
|
**Description:** Include `.desktop` files and icon assets that integrate with Linux desktop environments (GNOME, KDE, XFCE). This makes Weevil appear in application menus and launchers. Likely bundled with the .deb package.
|
|
|
|
**Rationale:** Makes Weevil discoverable in the GUI for users who aren't comfortable with terminals. Fits the "reduce cognitive load" philosophy.
|
|
|
|
**Pros:**
|
|
- Low effort (just create .desktop files)
|
|
- Helps GUI users discover Weevil
|
|
- Standard Linux desktop integration
|
|
|
|
**Cons:**
|
|
- Different desktop environments have quirks
|
|
- Icon design needed
|
|
- Only useful if there's a GUI to launch
|
|
|
|
**Priority:** MEDIUM - Pairs well with GUI development
|
|
|
|
---
|
|
|
|
### Non-Debian Linux Distribution Support
|
|
|
|
**Feature:** Support for Arch, Fedora, Slackware, and other distributions
|
|
|
|
**Description:** Adapt installation scripts to detect and use different package managers:
|
|
- Arch: pacman
|
|
- Fedora: dnf/yum
|
|
- Slackware: pkgtool
|
|
- Generic: compile from source instructions
|
|
|
|
May also include packaging for AUR (Arch User Repository), Fedora Copr, etc.
|
|
|
|
**Rationale:** Expands addressable market. Some teams use Arch or Fedora. Shows commitment to Linux ecosystem.
|
|
|
|
**Pros:**
|
|
- Broader Linux support
|
|
- Community contributions likely (Arch users love AUR packages)
|
|
- Demonstrates technical depth
|
|
|
|
**Cons:**
|
|
- Significant testing burden across distros
|
|
- Each package manager has different quirks
|
|
- Low ROI - most teams use Ubuntu/Debian or Windows
|
|
- Maintenance overhead
|
|
|
|
**Priority:** LOW-MEDIUM - Nice to have, but niche
|
|
|
|
---
|
|
|
|
### Graphical User Interface (GUI)
|
|
|
|
**Feature:** GUI application for teams uncomfortable with terminals
|
|
|
|
**Description:** A graphical interface that wraps Weevil's functionality, allowing users to:
|
|
- Create new projects through forms/wizards
|
|
- Configure project settings visually
|
|
- Run builds and deployments with buttons
|
|
- View status and logs in a window
|
|
- Manage dependencies through checkboxes/dropdowns
|
|
|
|
**Technical Approaches:**
|
|
1. **Tauri** - Rust + web frontend (HTML/CSS/JS), native performance, small binary
|
|
2. **Local web server** - Weevil serves HTML, opens browser automatically
|
|
3. **Native GUI** - GTK, Qt, or egui (Rust native GUI)
|
|
|
|
**Rationale:** Reduces barrier to entry for students and coaches unfamiliar with terminals. Lowers cognitive load - students focus on robotics, not command syntax. Particularly valuable for younger teams or schools with limited technical resources.
|
|
|
|
**Pros:**
|
|
- Significantly lowers barrier to entry
|
|
- Appeals to visual learners
|
|
- Makes Weevil accessible to non-programmers (coaches, parents)
|
|
- Could include visual project templates/wizards
|
|
- Positions Weevil as "real software" vs. "developer tool"
|
|
|
|
**Cons:**
|
|
- Substantial development effort
|
|
- GUI framework choice has long-term implications
|
|
- Need to maintain two interfaces (CLI + GUI)
|
|
- UI design and UX is its own skillset
|
|
- Testing GUI across platforms is complex
|
|
- May need separate binary or flag to launch GUI
|
|
|
|
**Priority:** MEDIUM-HIGH - Valuable for adoption, but requires careful planning
|
|
|
|
**Dependencies:** If building a GUI, having an API layer (see below) makes sense for architecture.
|
|
|
|
---
|
|
|
|
### REST API Layer
|
|
|
|
**Feature:** Internal API that both CLI and GUI can consume
|
|
|
|
**Description:** Refactor Weevil's core functionality behind a REST API:
|
|
- API could run as a local server or be embedded
|
|
- CLI becomes a thin client to the API
|
|
- GUI uses the same API endpoints
|
|
- Enables future integrations (VS Code extension, web dashboard, etc.)
|
|
|
|
Endpoints might include:
|
|
- `POST /project/create` - Create new project
|
|
- `GET /status` - System audit
|
|
- `POST /build` - Trigger build
|
|
- `GET /dependencies` - List installed dependencies
|
|
- etc.
|
|
|
|
**Rationale:** Clean separation of concerns. Makes adding new interfaces (GUI, IDE plugins) easier. Enables potential future features like remote builds or team collaboration.
|
|
|
|
**Pros:**
|
|
- Clean architecture
|
|
- Multiple frontends share same backend logic
|
|
- Easier testing (API can be tested independently)
|
|
- Opens door to remote/distributed features
|
|
- Could enable web-based dashboard for teams
|
|
|
|
**Cons:**
|
|
- Significant refactoring of existing code
|
|
- Adds complexity (serialization, HTTP layer, error handling)
|
|
- Local-only API doesn't provide much value initially
|
|
- May be over-engineering for current needs
|
|
- gRPC/Protobuf would be overkill unless remote features needed
|
|
|
|
**Priority:** LOW-MEDIUM - Nice architecture, but not essential unless building GUI or extensions
|
|
|
|
**Note:** If staying local-only, CLI calling library functions directly is simpler. Only build API if there's a concrete need (GUI, remote features, integrations).
|
|
|
|
---
|
|
|
|
## Version 1.3.0 - Extended Platform Support
|
|
|
|
(Features carried over from v1.2.0 if not completed, plus any new platform-specific enhancements)
|
|
|
|
---
|
|
|
|
## Version 1.4.0 - Ecosystem & Package Management
|
|
|
|
**Theme:** Transforming Weevil from a project generator into an ecosystem platform. This is where Weevil becomes more than what Android Studio offers.
|
|
|
|
### FTC Component Package Manager
|
|
|
|
**Feature:** Package manager for sharing and reusing FTC robot code components
|
|
|
|
**Description:** Enable teams to publish and consume reusable robot code components. Examples:
|
|
- Mechanim wheel controllers
|
|
- Sensor abstractions
|
|
- Autonomous routines
|
|
- Vision processing pipelines
|
|
- Hardware wrappers
|
|
|
|
**Potential Approaches:**
|
|
|
|
1. **Git Submodule Style (FreeBSD Ports):**
|
|
- Package index is a Git repository with manifests
|
|
- `weevil add mechanim-wheel` pulls code via Git into project
|
|
- Code is vendored locally, teams can modify
|
|
- Clean version control story
|
|
|
|
2. **Central Registry:**
|
|
- Nexus Workshops hosts package registry at nxgit.dev
|
|
- Teams publish packages with metadata (license, dependencies, version)
|
|
- `weevil search wheels` finds packages
|
|
- `weevil add team123/mechanim-wheel` installs
|
|
- Binary or source distribution
|
|
|
|
3. **Hybrid Approach:**
|
|
- Decentralized (anyone can host packages on Git)
|
|
- Nexus Workshops provides discovery/curation (searchable index)
|
|
- Teams can specify direct Git URLs or use curated registry
|
|
|
|
**Key Considerations:**
|
|
- **Licensing:** Must track and display licenses, ensure compliance
|
|
- **Namespacing:** Avoid collisions (team number prefixes? org namespaces?)
|
|
- **Versioning:** Semantic versioning, dependency resolution
|
|
- **Quality:** Curated vs. open submission, review process
|
|
- **Trust:** Code signing? Verified publishers?
|
|
|
|
**Rationale:** This is the network effect feature. Teams contribute back proven solutions. Nexus Workshops becomes the central hub for FTC software engineering knowledge. Competitive moat - no other tool offers this. Transforms FTC from "everyone reinvents wheels" to "community shares solutions."
|
|
|
|
**Pros:**
|
|
- Massive competitive differentiation
|
|
- Creates community around Weevil/Nexus Workshops
|
|
- Direct value to teams (stop reinventing proven solutions)
|
|
- Positions Nexus Workshops as FTC software authority
|
|
- Revenue potential (premium packages? consulting on custom components?)
|
|
- Network effects - more users = more packages = more value
|
|
|
|
**Cons:**
|
|
- Complex to implement correctly
|
|
- Licensing compliance is non-trivial
|
|
- Moderation/curation burden (prevent malicious code)
|
|
- Version conflicts and dependency hell
|
|
- Need critical mass of packages to be valuable
|
|
- Support burden (teams will ask for help with downloaded packages)
|
|
- Security concerns (code execution from third parties)
|
|
|
|
**Priority:** HIGH - This is the strategic differentiator for v1.4.0
|
|
|
|
**Success Criteria:**
|
|
- At least 10 high-quality packages at launch
|
|
- Clear licensing and attribution
|
|
- Simple `weevil add` and `weevil remove` workflow
|
|
- Nexus Workshops positions as curator/quality gatekeeper
|
|
|
|
---
|
|
|
|
## Version 1.5.0 - Language Expansion
|
|
|
|
**Theme:** Future-proofing Weevil for FTC's evolution
|
|
|
|
### C++ Language Support
|
|
|
|
**Feature:** Support for C++ FTC projects alongside Java
|
|
|
|
**Description:** If/when FTC officially supports C++ for robot programming, Weevil should support creating and managing C++ projects:
|
|
- C++ project templates
|
|
- Build system integration (CMake? Gradle?)
|
|
- Android NDK integration
|
|
- Debugging support
|
|
- Mixed Java/C++ projects (JNI bridges)
|
|
|
|
**Rationale:** Stay ahead of FTC changes. C++ may offer performance benefits for vision processing or complex algorithms. Supporting multiple languages positions Weevil as the universal FTC development tool.
|
|
|
|
**Pros:**
|
|
- Future-proofing
|
|
- Potential performance benefits for teams
|
|
- Differentiator if other tools don't support C++
|
|
- Demonstrates technical sophistication
|
|
|
|
**Cons:**
|
|
- Uncertain if FTC will actually support C++
|
|
- C++ toolchain complexity (NDK, build systems)
|
|
- Most teams won't need/want C++
|
|
- Significant development effort
|
|
- Testing burden (two language stacks)
|
|
|
|
**Priority:** LOW - Wait and see if FTC actually supports C++
|
|
|
|
**Trigger:** FTC officially announces C++ support
|
|
|
|
---
|
|
|
|
### Multi-Language Architecture
|
|
|
|
**Feature:** Plugin-based language support architecture
|
|
|
|
**Description:** If supporting multiple languages (Java, C++, potentially Kotlin), refactor Weevil to have a language-agnostic core with language-specific plugins:
|
|
- Core: project structure, build orchestration, deployment
|
|
- Plugins: language-specific templates, build rules, dependencies
|
|
|
|
This makes adding new languages easier and keeps core clean.
|
|
|
|
**Rationale:** Clean architecture for extensibility. Easier to maintain than language-specific code scattered throughout.
|
|
|
|
**Pros:**
|
|
- Cleaner codebase
|
|
- Community could contribute language plugins
|
|
- Future-proof for whatever FTC supports next
|
|
|
|
**Cons:**
|
|
- Significant refactoring
|
|
- May be over-engineering if only supporting Java + maybe C++
|
|
- Plugin API needs careful design
|
|
|
|
**Priority:** LOW-MEDIUM - Only if supporting 3+ languages
|
|
|
|
---
|
|
|
|
## Version 1.6.0+ - Advanced Tooling
|
|
|
|
**Theme:** Making Weevil an all-in-one development environment
|
|
|
|
### Troubleshooting Suite
|
|
|
|
**Feature:** Comprehensive diagnostic and debugging tools
|
|
|
|
**Description:** A suite of troubleshooting tools that help teams diagnose common problems:
|
|
|
|
**Potential Components:**
|
|
1. **Connectivity Diagnostics:**
|
|
- `weevil diagnose adb` - Check ADB connection to robot controller
|
|
- Detect USB vs. WiFi connection issues
|
|
- Test latency and connection stability
|
|
|
|
2. **Build Analysis:**
|
|
- Parse build errors and suggest fixes
|
|
- Detect common misconfigurations (wrong SDK version, missing dependencies)
|
|
- Gradle build cache issues
|
|
|
|
3. **Log Analysis:**
|
|
- `weevil logs analyze` - Parse robot logs for common errors
|
|
- Highlight crashes, exceptions, performance issues
|
|
- Suggest fixes based on error patterns
|
|
|
|
4. **Performance Profiling:**
|
|
- Measure loop times
|
|
- Identify performance bottlenecks in autonomous
|
|
- Memory usage analysis
|
|
|
|
5. **Code Quality Checks:**
|
|
- Static analysis for common mistakes
|
|
- Style guide compliance
|
|
- Anti-pattern detection (blocking operations in main loop, etc.)
|
|
|
|
6. **Interactive Troubleshooter:**
|
|
- Wizard-style troubleshooting ("What problem are you having?")
|
|
- Step-by-step guidance
|
|
- Link to documentation/solutions
|
|
|
|
**Rationale:** This is a game-changer for teams without experienced mentors. Most FTC teams struggle with debugging. Automated troubleshooting reduces frustration and keeps teams moving. Positions Nexus Workshops as the support resource.
|
|
|
|
**Pros:**
|
|
- High value - debugging is painful for teams
|
|
- Competitive advantage (no other tool offers this)
|
|
- Reduces support burden (self-service troubleshooting)
|
|
- Educational - teaches debugging skills
|
|
- Could integrate with package manager (suggest better packages)
|
|
|
|
**Cons:**
|
|
- Requires deep knowledge of common FTC issues
|
|
- Error pattern recognition is complex
|
|
- May give wrong advice (false positives)
|
|
- Maintenance as FTC SDK evolves
|
|
- Difficult to test comprehensively
|
|
|
|
**Priority:** MEDIUM-HIGH - Valuable but complex, needs careful design
|
|
|
|
**Implementation Note:** Could start simple (common error pattern matching) and evolve based on real team issues encountered through Nexus Workshops.
|
|
|
|
---
|
|
|
|
## Version 2.0.0 - Major Architectural Changes
|
|
|
|
**Theme:** Breaking changes that significantly improve Weevil but may require migration
|
|
|
|
**Potential Features:**
|
|
- Complete rewrite of core systems if architecture needs major overhaul
|
|
- Breaking changes to project structure
|
|
- New configuration format
|
|
- Major changes to CLI interface
|
|
- Integration with cloud services (build servers, team collaboration)
|
|
|
|
**Note:** Given the `weevil upgrade` command's ability to migrate projects, moving to 2.0.0 may not be necessary unless there are fundamental architecture changes that can't be backward compatible.
|
|
|
|
---
|
|
|
|
## Unscheduled / Research Needed
|
|
|
|
### Cloud Build Services
|
|
**Description:** Remote build servers for teams with slow computers. Teams push code, Weevil builds in the cloud, streams back APK.
|
|
|
|
**Status:** Research - needs cost/benefit analysis, infrastructure planning
|
|
|
|
---
|
|
|
|
### VS Code Extension
|
|
**Description:** Extension for VS Code to provide similar integration as Android Studio.
|
|
|
|
**Status:** Research - depends on VS Code adoption in FTC community
|
|
|
|
---
|
|
|
|
### Team Collaboration Features
|
|
**Description:** Features for teams to coordinate across multiple developers - shared configurations, code review integration, task tracking.
|
|
|
|
**Status:** Research - needs market validation (do teams want this?)
|
|
|
|
---
|
|
|
|
### Custom Hardware Support
|
|
**Description:** Templates and tools for teams using custom sensors or actuators beyond standard FTC parts.
|
|
|
|
**Status:** Research - depends on community need
|
|
|
|
---
|
|
|
|
## Versioning Philosophy
|
|
|
|
- **1.x.0 releases:** New features, backward compatible
|
|
- **1.x.y releases:** Bug fixes, patches, documentation
|
|
- **2.0.0:** Breaking changes requiring migration (avoid if possible)
|
|
|
|
The `weevil upgrade` command is designed to migrate projects forward across versions, making major version bumps less necessary.
|
|
|
|
---
|
|
|
|
## Success Metrics
|
|
|
|
How we'll measure if Weevil is succeeding:
|
|
|
|
- **Adoption:** Number of teams using Weevil (tracked via downloads, GitHub stars)
|
|
- **Retention:** Teams continuing to use across seasons
|
|
- **Nexus Workshops impact:** Does Weevil drive workshop signups or consulting engagement?
|
|
- **Community:** Package contributions, GitHub issues/PRs, community discussions
|
|
- **Competitive outcomes:** Do Nexus Workshops teams using Weevil perform better?
|
|
|
|
---
|
|
|
|
## Contributing to the Roadmap
|
|
|
|
This roadmap is subject to change based on:
|
|
- User feedback from FTC teams
|
|
- Technical feasibility discoveries
|
|
- Market competition
|
|
- Strategic priorities for Nexus Workshops LLC
|
|
|
|
Features may be accelerated, deferred, or cancelled as the project evolves.
|
|
|
|
---
|
|
|
|
*Last Updated: January 2026* |