We’re excited to share the latest updates on Taskitty ٩(⸝⸝ᵕᴗᵕ⸝⸝)و*̣̩⋆̩*

In this progress report, we’ll outline some Features, short tasks and Bugs, as well as unspecified yets.

Below, you’ll find a summary of what we’ve achieved so far.

*v0.9.0*
**short tasks**
✔ create project for taskitty free version aka Taskitty Lite (done in: 0.8.0)
**Other**
✔ refactoring scripts to work in playmode for Taskitty PlayMode asset

*v0.8.0*
**Bugs**
✔ when comment window is open, we cannot click anything in a card (done in: 0.7.1)
**unspecified yets**
✔ Dont drag lists when hover over scrollbar (done in: 0.7.1)
**Other**
✔ reworked the logo
✔ rebrand to URage
✔ can still drag lists when not actually hovered over them

This Progress Report was generated by Taskitty ≽^•⩊•^≼ – Learn More: https://urage.net/taskitty

 

Problem with the Unity Version and Added/Done Tasks

th eproblem: when the user doesn’t update the version, and he marks tasks as done or adding tasks after he made a release, those tasks will go to the older version. we need to tell the user to update the version first. but how detect the release?

  • to work around this, the user would need to increase the version by guessing the new version diretly after a release. *dirty*
  • also we would need to  handle v1.0/0.1

this was kinda a ride as well. so let’s summarize:

  • We wanted to use BuildPipeline.isBuildingPlayer but it somehow just doesn’t returns true. also it’s not available in Unity 2019
  • then we found out about IPreprocessBuildWithReport.OnPreprocessBuild and IPostprocessBuildWithReport.OnPostprocessBuild but those also aren’t available in Unity 2019
  • FileSystemWatcher so we’re independant of any unity versions and we would anyone need another approach for a later tool outside of Unity.
  • Finally we realized, we could just store the checksum in EditorPrefs and compare it with current one
  • But that results in Unity popping up a loading popup we could not get rid of yet. Tried Coroutines. Maybe a Thread?

update done in versions on version change with a 2nd info “finalDoneInVersion” so we dont double update them?
Do we need a “released in version” info for our tasks?

added in = came up in
done in = fixed in x available in y

(what if there will never be a build but an  export that counts as release cause it’s an asset or other project instead of a game?)
add ability to change added in and done in verrsion if everything fails

we are doing a progress report for v0.1.1 for tasks thas have been done in v0.1.0 after we made a release

so if we mark a task as done or add a new task after a release, ask the user if that task is for the new version. note that we can’t expect the user to guess the new version, since there could be a bug fix first and then a feature implementation in the same version. so first it would be 0.1.1 but then we realize it’s 0.2.0. so we use the flag.

also maybe show a notification popup to inform when version has increased and maybe ask if the release happened, to close pending done tasks)

and suggest new version in config panel. would be cool to have an option in a tag to set major.minor.patch  automatically. “feature” is minor. “bug” is patch. “milestone” is “major”

what if we make 2 releases without mark done or add tasks in a version? we would need the filewatcher again.

szenario 1:

0.1.0:

-create a cube

initial release (this is prob important)

-scale the cube (added in 0.1.0)

-mark done (done in 0.1.0)

[increase to 0.1.1]

0.1.1

-release 0.1.1

 

szenario 2:

0.1.0:

-create a cube

initial release (this is prob important)

-scale the cube (added in 0.1.0)

[increase to 0.1.1]

0.1.1

-mark done (done in 0.1.1)

-release 0.1.1

 

szenario 3:

0.1.0:

-create a cube

initial release (this is prob important)

[increase to 0.1.1]

0.1.1

-scale the cube (added in 0.1.1)

-mark done (done in 0.1.1)

-release 0.1.1

 

szenario 4a:

0.1.0:

-create a cube

initial release (this is prob important)

-scale the cube (added in 0.1.0)

-mark done (done in 0.1.0)

-release 0.1.1

[increase to 0.1.1]

0.1.1:

 

szenario 4b:

0.1.0:

-create a cube

initial release (this is prob important)

-scale the cube (added in 0.1.0)

-release 0.1.1

-mark done (done in 0.1.0)

[increase to 0.1.1]

0.1.1:

Taskitty PlayMode

“>

    https://unsplash.com/photos/YS_FCbcD5KM

    https://unsplash.com/photos/YS_FCbcD5KM

    https://unsplash.com/photos/YS_FCbcD5KM

    https://unsplash.com/photos/YS_FCbcD5KM